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ABSTRACT 


This  case  study  analyzes  how  the  Stryker  Mobile  Gun  System  (MGS) 
program  managed  complexity.  The  MGS  is  one  of  the  ten  variants  of  the  Stryker 
series  of  vehicles  that  equip  the  Army’s  Stryker  Brigade  Combat  Teams.  These 
brigades  were  created  by  the  Army  Chief  of  Staff  from  1999-2003,  General  Eric 
Shinseki,  to  provide  the  Army  with  a  highly  deployable  medium-force  capability. 
Initially  intended  as  a  variant  that  required  limited  development,  the  MGS 
experienced  a  number  of  significant  challenges  during  systems  development. 

This  case  study  uses  one  of  the  program’s  primary  issues,  reliability 
shortfalls  with  the  ammunition  handling  system,  to  describe  how  the  program 
self-organized  to  manage  complexity.  The  case  study  identifies  the  elements  of 
complexity  that  existed  in  the  Defense  Acquisition  System  (DAS),  and  how  they 
interacted  to  create  a  challenging  situation  for  the  MGS  program. 

After  a  crisis  period  from  2004-2005,  the  MGS  program  changed  its 
acquisition  approach  through  the  revitalization  of  systems  engineering  and  risk 
management.  This  case  study  examines  the  self-organizing  methods  that  the 
MGS  program  used  to  improve  system  performance,  and  it  concludes  with  a 
description  of  how  acquisition  programs  can  better  align  their  acquisition  strategy 
to  achieve  programmatic  resilience. 
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I.  INTRODUCTION 


A.  DIYALA  PROVINCE,  2008 

The  platoon  sergeant  from  Alpha  Company,  1st  Battalion,  38th  Infantry 
Regiment  had  thoroughly  prepared  his  Mobile  Gun  System  (MGS)  platoon  for 
their  reconnaissance  mission  in  the  Diyala  Province,  an  area  northeast  of 
Baghdad  that  was  a  hotbed  of  insurgent  activity.  With  over  19  years  in  the  Army, 
the  platoon  sergeant  understood  the  process  of  preparing  Soldiers  for  a  mission, 
known  as  Troop  Leading  Procedures,  and  he  was  aware  of  the  potential 
problems  that  could  easily  arise  in  such  a  complex  environment.  The  Army  trains 
its  tactical  leaders  to  integrate  the  Troop  Leading  Procedures  as  early  as 
possible  in  the  planning  process  and  to  maximize  the  use  of  time. 

The  platoon’s  mission  from  their  higher  headquarters  was  to  “get  eyes  on” 
a  small  town  in  their  sector  by  using  the  sophisticated  array  of  day  and  night 
optics  on  the  MGS  (see  Figure  1)  (Pappalardo,  2008,  March  11).  To  visualize 
the  battlefield,  the  platoon  sergeant  used  the  limited  amount  of  information  that 
he  had  on  the  enemy  and  the  three-dimensional  terrain  to  build  situational 
understanding  for  the  platoon,  but  he  knew  that  this  picture  was  imperfect.  While 
moving  to  their  observation  point,  the  platoon  sergeant’s  MGS  was  struck  by  an 
improvised  explosive  device  (IED)  “that  blew  out  eight  tires  and  one  antenna 
mount”  (Pappalardo,  2008,  March  11).  Although  the  tremendous  blast  jarred  the 
crew,  they  were  able  to  execute  one  of  their  contingency  plans  and  move  the 
vehicle  to  a  secure  area  2600  meters  away  to  execute  their  preplanned  battle 
damage  and  repair  procedures  (Pappalardo,  2008,  March  11). 

During  mission  planning,  the  MGS  platoon  leadership  identified  hazards 
and  developed  controls  to  mitigate  those  risks  in  a  process  known  as  risk 
management  (TRADOC,  2005,  November  20,  p.  E-1 ).  The  effectiveness  of  the 
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risk  management  process  requires  situational  understanding  and  controls  that 
the  platoon’s  leadership  adapts  to  the  particular  hazard  and  situation  (TRADOC, 
2005,  November  20,  p.  E-1). 


Figure  1.  M-1128  MGS  (From  GDLS,  2005c,  slide  2) 


Soon  after  they  conducted  the  battle  damage  and  assessment  drill  and 
brought  the  vehicle  to  an  operational  status,  the  platoon  got  back  onto  the  road. 
Within  minutes  of  getting  the  platoon  back  onto  the  road,  a  second  IED  struck  the 
platoon  sergeant’s  vehicle  (Pappalardo,  2008,  March  11).  This  time,  the  crew’s 
gunner  was  able  to  identify  “the  triggerman  on  the  roof  of  a  building  820  feet 
away”  and  with  no  tires  or  communications  equipment,  the  platoon  sergeant’s 
vehicle  was  able  to  “engage  the  spotter  with  20  rounds  [7.62mm  machine  gun], 
while  on  the  move  to  eliminate  the  threat”  (Pappalardo,  2008,  March  11). 
Despite  two  IED  strikes,  the  platoon  maintained  its  resiliency  in  the  face  of 
uncertainty  and  completed  its  mission  without  the  loss  of  life. 

Risks  are  an  inherent  part  of  any  mission,  and  the  platoon  was  able  to 
complete  its  mission  because  their  leaders  properly  anticipated  these  risks  and 
developed  controls  to  reduce  the  severity  of  the  consequences.  During  the 
mission,  the  platoon  sergeant  demonstrated  the  integration  of  risk  management 
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and  knowledge  management  into  his  Troop  Leading  Procedures.  The 
synchronization  of  these  processes  was  critical  to  his  platoon’s  ability  to 
accomplish  the  mission  without  the  loss  of  life.  Yet,  the  synchronization  of  these 
processes  required  the  application  of  the  platoon  sergeant’s  will  and  an 
understanding  of  battle  command. 

B.  SYSTEMS  ACQUISITION:  A  COMPLEX  AND  UNCERTAIN  MISSION 

In  a  similar  manner  to  the  behavior  of  the  tactical  leader  in  the  Diyala 
vignette,  the  program  manager  must  synchronize  his  or  her  program  in  time  and 
space  to  achieve  effective  results  while  navigating  a  complex  and  uncertain 
defense  acquisition  system.  Just  as  the  MGS  platoon  sergeant  synchronized  risk 
management  and  knowledge  management  into  his  Troop  Leading  Procedures, 
the  program  manager  must  do  the  same  to  exercise  resilient  and  agile  program 
management.  The  program  manager  must  also  work  with  imperfect  information 
while  making  decisions  on  development,  testing,  production,  and  logistical 
support  that  will  affect  the  program  over  its  entire  lifecycle. 

The  Mobile  Gun  System,  one  of  the  ten  variants  of  the  Stryker  series  of 
vehicles,  conducted  its  first  operational  deployment  to  Iraq  as  part  of  the  4th 
Stryker  Brigade  Combat  Team,  2nd  Infantry  Division  in  2007.  During  its  first 
operational  deployment  to  Iraq,  the  MGS  received  positive  feedback  and  in  the 
words  of  the  platoon  sergeant  from  the  Diyala  vignette,  “it  is  the  most  lethal 
ground  vehicle  for  an  urban  environment  in  Iraq  today”  (Pappalardo,  2008,  March 
1 1 ).  However,  the  vehicle  experienced  a  challenging  development  process. 

C.  RESEARCH  QUESTION  AND  METHODOLOGY 

1.  Research  Question 

This  case  study  had  one  primary  research  question:  How  did  the  Mobile 
Gun  System  Program  Management  Office  (MGS  PMO)  manage  complexity? 
From  the  primary  research  question,  the  research  developed  several  supporting 
research  questions: 
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•  What  was  a  significant  developmental  problem  experienced  by  MGS 
that  required  the  MGS  program  to  revise  its  approach? 

•  What  was  the  root  cause  of  the  developmental  problem  and  what 
corrective  actions  did  the  program  management  office  take  to  improve 
the  system? 

•  What  is  complexity  theory  and  how  does  it  apply  to  products  and 
systems? 

•  How  did  the  MGS  PMO  self-organize  to  adapt  to  the  complex 
environment  and  what  insights  can  the  case  study  use  to  apply  to  other 
systems  acquisition  programs? 

2.  Methodology 

This  case  study  focused  on  the  program’s  first  six  years  of  development 
from  2000-2006,  which  provided  the  case  study  with  a  historical  perspective. 
The  case  study  used  a  specific  issue  encountered  during  the  MGS  development 
as  a  means  to  study  how  complexity  affected  one  particular  systems  acquisition 
program.  The  case  study  then  identified  the  methods,  techniques,  and 
approaches  that  the  MGS  Product  Management  Office  (MGS  PMO)  and  the 
prime  contractor,  General  Dynamics  Land  Systems  (GDLS),  used  to  manage  the 
complexity. 

The  first  step  in  the  research  process  was  to  obtain  information  for  the 
case  study  from  several  different  sources.  The  researcher  focused  on 
documents  and  information  available  through  open  sources  such  as  defense 
publications  and  newspapers.  The  researcher  then  transitioned  to  a  literature 
review  on  complexity  theory. 

The  next  step  in  the  research  process  was  to  interview  members  of  the 
Project  Management  Office  for  the  Stryker  Brigade  Combat  Team  (PM  SBCT). 
Since  the  development  of  the  MGS  is  still  in  progress,  many  of  the  program’s  key 
participants  were  available  for  interviews.  These  interviews  played  a  critical  role 
in  providing  information  for  the  case  study.  As  part  of  the  research  process,  the 
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author  arranged  interviews  with  current  and  former  government  and  private 
sector  individuals  who  were  involved  with  the  development  of  the  MGS  both 
directly  and  indirectly. 

According  to  Robert  K.  Yin,  the  author  of  Case  Study  Research,  the 
researcher  should  approach  a  case  study  as  an  open-ended  investigation  (Yin, 
2003,  p.  90).  Each  interview  served  as  a  source  of  information,  but  the  research 
had  to  corroborate  all  of  the  information  gained  from  the  interview  to  present  a 
clear  and  concise  case.  When  conducting  the  interviews,  the  author  focused  the 
questions  on,  “satisfying  the  needs  of  [the  case  study’s]  own  line  of  inquiry  while 
simultaneously  putting  forth  friendly  and  non-threatening  questions  in  open 
ended  interviews”  (Yin,  2003,  p.  90). 

3.  Limitations 

The  case  study  attempts  to  fill  some  of  the  gap  between  the  literature  on 
complexity  in  the  defense  acquisition  environment  and  the  literature  on  how 
program  management  offices  manage  complexity.  The  case  study  uses  a  recent 
Army  acquisition  program  to  provide  relevant  lessons  learned  for  acquisition 
professionals. 

The  case  study  has  two  main  limitations.  First,  it  attempts  to  draw 
conclusions  on  how  an  acquisition  program  managed  complexity  by  analyzing  a 
segment  in  time,  2000-2006.  The  case  study  also  focused  on  one  specific 
development  issue,  reliability  growth.  The  main  limitation  of  this  approach  is  that 
it  does  not  fully  address  everything  that  the  MGS  PMO  conducted  during  this 
period. 

Second,  the  author  was  able  to  interview  a  broad  range  of  individuals  from 
both  the  government  and  the  private  sector  for  the  case  study,  but  it  is  possible 
that  bias  existed  within  the  interview  content.  To  mitigate  this,  the  author 
interviewed  several  individuals  from  multiple  periods  to  increase  the  level  of 
objectivity. 
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D.  ORGANIZATION  OF  THE  CASE  STUDY 

The  case  study  specifically  addresses  one  critical  challenge  of  the  MGS 
development,  but  in  a  wider  sense,  this  is  not  the  purpose  of  the  case  study.  The 
discussion  of  the  reliability  shortfalls  is  merely  a  means  of  discussing  how 
programs  self-organize  in  the  face  of  complexity.  Therefore,  it  was  necessary  to 
start  from  a  very  broad  perspective  when  addressing  the  Mobile  Gun  System 
program’s  management  of  complexity. 

In  Chapter  I,  the  case  study  introduces  the  research  question,  the 
methodology,  and  the  organization  of  the  case  study.  The  opening  discussion  on 
the  Diyala  vignette  frames  the  case  study’s  analysis. 

Chapter  II,  “What  is  Complexity,”  introduces  complexity  theory,  and  it 
starts  from  a  very  broad  perspective  with  a  discussion  of  several  different 
theories.  As  the  chapter  progresses,  it  focuses  the  discussion  on  complex 
programs.  In  addition  to  discussing  complexity  in  programs,  Chapter  II  also 
discusses  the  use  of  systems  engineering,  risk  management,  and  strategic 
planning. 

In  Chapter  III,  “The  Road  to  Stryker,”  the  case  study  provides  a  context  to 
the  outer  environment  that  led  to  the  Interim  Force,  which  was  later  renamed 
Stryker.  Chapter  III  discusses  the  Stryker’s  champion,  General  Eric  Shinseki, 
who  articulated  the  vision  for  the  Interim  Force  during  the  October  1999 
Association  of  the  United  States  Army  convention.  “The  Road  to  Stryker”  also 
discusses  how  the  acquisition  reforms  of  the  1990s  affected  the  Stryker  program 
as  well  as  the  urgency  of  the  program. 

Chapter  IV,  “The  Development  of  MGS,”  provides  a  more  focused 
discussion  on  the  MGS.  In  this  chapter,  the  case  study  describes  the  unique 
requirements  of  the  MGS  and  the  approach  that  the  program  manager  took  in 
developing  the  system.  Chapter  IV  also  provides  a  chronological  history  of  the 
development  through  2008  to  familiarize  the  reader  with  the  program. 

Chapter  V,  “Managing  Complexity,”  focuses  on  the  reliability  issues 
associated  with  the  MGS  ammunition  handling  system.  The  chapter  then 
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analyzes  how  the  program  self-organized  during  a  crisis.  The  chapter  closes 
with  a  discussion  on  the  application  of  complexity  theory  to  the  MGS.  During  this 
discussion,  the  author  develops  several  insights  on  the  key  aspects  of  the 
program’s  self-organization. 

Chapter  VI,  “Conclusion  and  Lessons  Learned,”  takes  the  insights  from 
Chapter  V  and  discusses  program  synchronization  with  a  wider  perspective. 
Chapter  VI  then  closes  with  six  lessons  learned  along  with  several 
recommendations  for  other  systems  acquisition  programs. 
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II.  COMPLEXITY— A  LITERATURE  REVIEW 


A.  INTRODUCTION 

To  gain  a  greater  appreciation  for  the  concept  of  complexity  in  product 
development,  this  case  study  cast  a  broad  net,  starting  with  a  review  of  several 
seminal  perspectives  on  complexity.  This  literature  review  progressively  scopes 
the  subject  of  complexity  from  a  broad  discussion  to  one  focused  on  products 
and  systems.  The  purpose  of  this  chapter  is  to  describe  the  theoretical 
framework  for  the  case  study,  with  a  focus  on  complexity. 

The  MGS  program  encountered  complexity  both  internally  and  externally 
during  its  development.  Before  delving  into  the  nuances  of  the  MGS  program’s 
complex  environment,  it  is  important  to  understand  the  sources  of  complexity. 
Maier  and  Rechin  (2000)  provide  a  strong  case  for  understanding  the  sources  of 
complexity  when  studying  technical  problems: 

It  is  generally  agreed  that  increasing  complexity  is  at  the  heart  of 
the  most  difficult  problems  facing  today’s  systems  architecting  and 
engineering.  When  architects  and  builders  are  asked  to  explain 
cost  overruns  and  schedule  delays,  by  far  the  most  common,  and 
quite  valid,  explanation  is  that  the  system  is  much  more  complex 
than  originally  thought.  The  greater  the  complexity,  the  greater  the 
difficulty,  (p.  24) 

It  is  not  the  intent  of  this  literature  review  to  provide  an  exhaustive  review 
of  all  sources  on  complexity;  rather,  this  chapter  discusses  how  complexity 
relates  to  products  and  systems.  This  section  provides  several  theoretical  views 
on  complexity,  a  description  of  complex  products  and  systems,  characteristics  of 
management  systems  for  complex  systems,  potential  problems  encountered  with 
the  management  of  complex  systems,  the  use  of  the  systems  approach,  risk 
management,  and  strategic  planning  in  complex  programs. 
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B.  WHAT  IS  COMPLEXITY? 

The  term  “complexity”  frequently  describes  anything  that  consists  of  many 
interrelated  parts  or  is  difficult  to  explain  in  simple  terms.  One  can  easily  find 
over  thirty  definitions  of  complexity  from  different  sources,  and  this  section  will 
start  by  discussing  three  of  these  definitions.  These  perspectives  are  from  Stuart 
A.  Kauffman,  Herbert  A.  Simon,  and  Peter  M.  Senge. 

1.  Self-Organization 

In  The  Origins  of  Order,  Kauffman  (1993)  provides  a  view  of  complexity 
from  a  physical  and  biological  standpoint.  Within  a  complex  network,  he 
discusses  three  regimes  of  behavior  that  include  ordered,  complex,  and  chaotic 
(Kauffman,  1993,  p.  183).  The  complex  regime  is  an  area  on  the  border  between 
order  and  chaos.  The  dynamics  of  this  complex  regime  are  sensitive  to  the  initial 
conditions  and  can  easily  change,  based  on  the  parameters.  Once  parameters 
are  changed,  Kauffman  describes  the  small  and  large  changes  within  the 
complex  regime  as  “avalanches”  that  affect  the  entire  system  (1983,  p.  174).  He 
refers  to  systems  that  are  able  to  adapt  to  the  changes  in  parameters  as  “self¬ 
organizing,”  and  this  occurs  through  the  accumulation  of  useful  variations 
(Kauffman,  1993,  p.  174).  While  Kauffman  addresses  the  complex  regime  that 
bordered  on  chaos  and  order,  Simon  sees  complexity  in  hierarchical  terms. 

In  The  Sciences  of  the  Artificial,  Herbert  A.  Simon  (1981)  refers  to 
complexity  as  something  that  is  “made  up  of  a  large  number  of  parts  that  interact 
in  a  non-simple  way”  (1981,  p.  195).  Simon  believed  that  complexity  was 
hierarchical  in  nature  and  that  each  system  within  the  hierarchy  had  its  own 
unique  sub-systems.  He  describes  this  as  a  “box  within  a  box,”  with  each 
complex  system  consisting  of  both  an  inner  and  outer  environment  (Simon,  1981, 
p.  148).  The  outer  environment  serves  as  the  operating  environment  for  the 
inner  environment,  and  the  outer  environment  is  the  inner  environment’s  primary 
source  of  complexity.  For  its  part,  the  inner  environment  is  constantly  adapting 
and  insulating  itself  from  the  variations  emerging  from  the  outer  environment;  he 
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refers  to  this  concept  as  a  “design  problem”  (Simon,  1981,  p.  134).  The  inner 
environment’s  design  quality  also  depends  on  the  limited  data  available  from  the 
outer  environment,  and  this  leads  to  a  high  level  of  uncertainty  and  ambiguity. 

In  Rationality  as  Process  and  as  Product  of  Thought,  Simon  stated  that  “in 
complex  situations  there  is  likely  to  be  a  considerable  gap  between  the  real 
environment  of  a  decision  and  the  environment  as  the  actors  perceive  it  (1978, 
May,  p.  8).  When  a  decision  maker  addresses  uncertainty  and  gaps  in 
perception,  he  or  she  can  either  satisfice  or  seek  an  optimal  solution.  Satisficing 
occurs  when  the  search  for  a  solution  “terminates  when  the  best  offer  exceeds 
an  aspiration  level  that  itself  adjusts  gradually  to  the  value  of  the  offers  received 
so  far”  (Simon,  1978,  p.  10).  Optimizing  occurs  when  the  “correct  point  of 
termination  is  found  by  equating  the  marginal  cost  of  search  with  the  marginal 
improvement  in  the  set  of  alternatives”  (Simon,  1978,  p.  10).  In  many  situations, 
the  uncertainty  of  the  situation  causes  the  decision-maker  to  arrive  at  intuitive 
decisions  that  are  good  enough.  Two  methods  for  satisficing  are  using  “feedback 
to  correct  for  unexpected  or  incorrectly  predicted  events”  and  feed-forward,  which 
is  “based  on  predictions  of  the  future,  in  combination  with  feedback,  to  correct  the 
errors  of  the  past”  (Simon,  1981,  p.  44).  Feed-forward  requires  some  awareness 
of  the  predicted  consequences  of  decisions. 

Feed-forward  is  challenging  for  organizations  because  people  have 
difficulty  maintaining  awareness  over  such  a  large  number  of  potentially  relevant 
considerations  (Simon,  1978,  p.  8).  Over  time,  these  organizations  learn  “in  the 
form  of  reaction  to  perceived  consequences,”  and  this  learning  is  the  dominant 
way  that  rationality  develops  in  an  environment  of  uncertainty  (Simon,  1978,  p. 
8).  The  large  number  of  potential  considerations  makes  a  situation  or  problem 
complex.  The  interrelated  nature  of  these  problems  makes  rational  decision¬ 
making  more  difficult  because  of  the  second-  and  third-order  consequences. 

2.  Dynamic  versus  Detail  Complexity 

Senge  (2007),  the  author  of  The  Fifth  Discipline,  differentiates  problems 

that  exhibit  detail  complexity  and  dynamic  complexity.  Detail  complexity  consists 
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of  a  brief  snapshot  in  time  of  a  relatively  static  system  in  which  there  are  many 
different  variables  to  explain  cause  and  effect  (Senge,  2007,  p.  71).  The 
preponderance  of  analytical  and  forecasting  tools  that  are  currently  used  address 
detail  complexity.  Problem-solvers  who  are  accustomed  to  solving  problems 
involving  detail  complexity  frame  the  problem  as  a  closed  event  in  terms  of  time 
and  space.  However,  the  analytical  and  forecasting  tools  that  use  detail 
complexity  do  not  provide  a  clear  cause  and  effect  with  dynamic  complexity 
because  cause  and  effect  are  “subtle  and  the  consequences  of  actions  occur 
over  time”  (Senge,  2007,  p.  71).  Senge  describes  several  situations  in  which 
dynamic  complexity  may  exist  including: 

When  the  same  action  has  dramatically  different  effects  in  the  short 
and  long  run  [...],  when  an  action  has  one  set  of  consequences 
locally  and  a  very  different  set  of  consequences  in  another  part  of 
the  system  [...  and]  when  obvious  interventions  produce  non- 
obvious  consequences.  (2007,  p.  71) 

Senge  believes  that  dynamic  complexity  was  the  source  of  most  problems 
and  that  the  key  to  understanding  it  was  the  identification  of  patterns  and 
relationships  in  variables.  Unlike  the  variables  in  detail  complexity,  the  variables 
in  dynamic  complexity  are  interdependent  and  difficult  to  separate.  Since  most 
problem-solvers  look  at  problems  in  terms  of  brief  snapshots  in  time  and  in  a 
relatively  linear  manner,  finding  the  actual  source  of  an  issue  is  problematic. 
From  Senge’s  perspective,  individuals  should  view  a  dynamic  problem  in  a 
holistic  manner  with  a  systems  approach. 

Senge  also  believes  that  the  dynamic  nature  of  these  problems  requires 
organizations  that  excel  at  learning.  Complex  and  dynamic  systems  require 
cross-functional  teams  made  up  of  “people  who  need  one  another  to  act”  (Senge, 
2007,  p.  219).  The  centerpiece  of  this  effort  is  “collaborative  learning,”  where 
teams  engage  in  open  dialogue  and  explore  complex  issues  from  many 
perspectives  (Senge,  2007,  p.  221).  Senge  identifies  three  critical  dimensions  for 
team  learning  in  organizations:  1)  think  insightfully  about  complex  issues,  2) 
utilize  innovative,  coordinated  action,  and  3)  understand  the  roles  of  team 
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members  on  other  teams  (2007,  p.  219).  A  key  impediment  to  the  use  of  the 
systems  approach  is  the  existence  of  defensive  routines  that  blur  the  facts  or  the 
reality  of  the  situation.  Effective  teams  can  nullify  these  defensive  routines  by 
embracing  conflicting  ideas  and  by  ensuring  the  free  flow  of  information,  both  bad 
and  good. 

The  common  theme  within  each  perspective  is  that  complexity  occurs  in 
many  different  environments  and  situations  but  mainly  in  moving  or  dynamic 
systems  in  which  adaptation  occurs  in  subtle  and  non-linear  ways. 

C.  COMPLEXITY  IN  PROGRAMS 

Both  Kauffman  (1993)  and  Simon  (1981)  view  the  outer  environment  as 
the  primary  source  of  complexity.  In  a  similar  manner,  Marco  lansiti  (1995),  the 
author  of  Technology  Integration:  Managing  Technological  Evolution  in  a 
Complex  Environment  views  a  complex  product  as  the  adaptation  to 
“requirements  from  an  organization’s  existing  environment”  (p.  521).  A  product  is 
the  result  of  the  fusion  of  technical  concepts  and  existing  knowledge  within  an 
organization.  In  his  view,  complexity  in  new  product  development  originates  from 
the  requirements,  sources  of  knowledge,  and  processes  that  lead  to  the  creation 
of  the  product  itself  (lansiti,  1995,  p.  522).  For  a  comprehensive  discussion  of  a 
Complex  Product  System,  Mike  Hobday  (1998),  the  author  of  Product 
Complexity,  Innovation  and  Industrial  Organization,  provides  a  clear  definition 
and  a  list  of  factors  that  contribute  to  product  complexity. 

Hobday  (1998)  defines  a  complex  product  or  system  as  “any  high  cost, 
engineering-intensive  product,  sub-system,  system  or  construct  supplied  by  a 
unit  of  production”  (p.  2).  Many  of  these  complex  products  are  the  result  of  new 
and  emerging  technology  and  involve  “high  levels  of  uncertainty  and  risk” 
(Hobday,  1998,  p.  5).  Hobday  also  provides  a  list  of  interdependent  product 
dimensions  that  characterize  complex  products.  These  factors  include: 

•  Unit  cost/financial  scale  of  project, 

•  Product  volume, 

•  Degree  of  technological  novelty, 
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•  Extent  of  embedded  software  in  the  product, 

•  Quantity  of  sub-systems  and  components, 

•  Degree  of  customization  of  components, 

•  Complexity  and  choice  of  system  architectures, 

•  Quantity  of  alternative  component  design  paths, 

•  Feedback  loops  from  later  to  earlier  stages, 

•  Variety  of  distinct  knowledge  bases, 

•  Variety  of  skills  and  engineering  inputs, 

•  Intensity  of  user  involvement, 

•  Uncertainty/change  in  user  requirements, 

•  Intensity  of  other  supplier  involvement,  and 

•  Intensity  of  regulatory  involvement  (Hobday,  1998,  p.  10) 

These  product  dimensions  increase  the  difficulty  of  coordination  and  systems 
architecture,  and  they  make  coordination  among  contributing  stakeholders  an 
essential  element  of  success. 

Robert  W.  Rykroft  and  Don  E.  Kash  (1999)  discuss  complexity  in  product 
development  in  their  book  The  Complexity  Challenge:  Technological  Innovation 
for  the  21st  Century.  Rykroft  and  Kash  define  technological  complexity  as  “any 
technology  that  could  not  be  understood  in  detail  by  an  expert  individual”  (1999, 
p.  54).  They  provide  several  conceptualizations  of  product  complexity  that 
include  the  number  of  components  in  a  system,  the  “relationship  between 
process  and  product  technologies,”  and  the  use  of  feedback  loops  to  self-adjust 
or  self-correct  system  attributes  known  as  cybernetics  (Rykroft  &  Kash,  1999,  p. 
55).  They  describe  the  complex  systems  emerging  from  technological  innovation 
as  a  combination  of  craft  production  and  mass  production  that  are  characterized 
by  a  “high  degree  of  risk  and  uncertainty,  a  constant  sense  of  novelty,  a  drive  to 
solve  new  problems,  and  above  all,  a  lot  of  trial-and-error  searching  and  non¬ 
linear  learning”  (Rykroft  &  Kash,  1999,  p.  28). 
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The  sense  of  novelty  that  characterizes  the  development  of  complex 
systems  means  that  learning  organizations  must  have  a  core  competency  in 
accumulating  and  transferring  information  as  well  as  a  proven  process  to  reflect 
on  new  information  (Rykroft  &  Kash,  1999,  p.  62).  The  pressure  of  meeting  a 
time-to-market  requires  the  organization  to  embrace  “error-embracing  behavior” 
in  order  to  gain  insights  on  complex  systems  during  their  development  (Rykroft  & 
Kash,  1999,  p.  63).  However,  error-embracing  behavior  does  not  produce 
substantial  improvements  in  time-to-market  unless  organizations  understand  the 
importance  of  communication  throughout  the  organizational  network. 

These  perspectives  provide  similar  discussions  on  complex  product 
characteristics,  the  use  of  feedback  loops,  self-correcting  systems,  and  non¬ 
linear  learning.  The  drive  to  field  these  complex  systems  at  a  faster  rate  while 
adapting  to  a  changing  environment  requires  a  seamless  relationship  between 
technology  and  the  organization. 

1 .  Characteristics  of  Management  Systems 

Numerous  models  provide  a  framework  for  creating  a  new  product  and 
managing  its  development.  Roy  C.  Rothwell  (1992),  the  author  of  Successful 
Industrial  Innovation:  Critical  Factors  for  the  1990s,  provides  a  useful  description 
of  five  generations  of  innovation  processes,  starting  in  the  1960s.  The  first  two 
generations  of  models  describe  “technology-push”  and  “need  pull”  as  linear  and 
sequential  models  of  development  (Rothwell,  1992,  p.  221).  The  third  generation 
model  continues  the  use  of  a  sequential  process,  but  it  also  included  the  use  of 
feedback  loops.  The  fourth  generation  model  of  the  1980s  went  to  the  use  of  a 
parallel  process  to  cut  down  on  cycle-time  and  emphasized  integration  between 
R&D  and  manufacturing.  The  fifth  generation  model  of  the  1990s  included  the 
use  of  parallel  processes  and  systems  integration,  with  an  emphasis  on 
collaboration  among  organizations  (Rothwell,  1992,  p.  221). 

Although  Hobday  did  not  differentiate  the  five  generations  of  industrial 
innovation,  he  concurred  with  Rothwell  that  complex  products  and  systems  do 

not  follow  the  “conventional  model”  of  development  (Hobday,  1998,  p.  18).  He 
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emphasized  that  the  key  difference  between  complex  products  and  systems  and 
simple  systems  was  user  involvement  because  they  were  “individually  developed 
and  tailored  [...]  for  a  particular  customer”  (Hobday,  1998,  p.  19).  Rykroft  and 
Kash  (1999)  strongly  endorse  the  importance  of  strong  collaboration  between  the 
user  and  the  system  developer. 

Rykroft  and  Kash  contend  that  the  use  of  the  linear  model  works  well  with 
mature  technology  in  a  mass  production  environment  but  is  ill-suited  for  the 
development  of  tailored,  complex  systems  because  it  detracts  from  rapid 
decision-making  (Rykroft  &  Kash,  1999,  p.  59).  The  user  and  marketplace 
demand  for  complex  technology  requires  a  faster  cycle-time  using  non-linear 
concurrent  models.  These  models  accentuate  collaboration  among  many 
different  organizations,  firms,  and  agencies  and  “error-embracing  behavior” 
(Rykroft  &  Kash,  1999,  p.  63).  To  reduce  cycle-time,  Rothwell  identified  a 
number  of  factors  that  influenced  a  “time-based  strategy”  including  those  listed 
below. 

•  Adequate  preparation:  careful  project  evaluation,  analysis,  and 
planning  as  well  as  gaining  the  commitment  of  those  who  will  be 
involved  in  the  project, 

•  Efficient  indirect  development  activities:  project  control,  administration, 
and  coordination  50%  of  total  project  time, 

•  Adopting  a  more  horizontal  management  style  with  increased  decision¬ 
making  at  lower  levels, 

•  Efficient  upstream  data  linkages  and  an  inter-company  liaison: 
involving  primary  suppliers  at  an  early  stage  of  development, 

•  Use  of  integrated  teams  during  development  and  prototyping, 

•  Modifying  the  development  process:  maximizing  the  use  of  simulation 
models  through  the  use  of  expert  systems, 

•  Incremental  improvement  strategy:  continuous  improvements  of 
existing  products, 


16 


•  Carry-over  strategies:  use  of  significant  elements  of  earlier  models  in 
the  most  recent  designs, 

•  Designed-in  flexibility:  creation  of  flexible  designs, 

•  Fuller  organizational  and  systems  integration:  minimize  number  of 
reporting  layers,  and 

•  Fully  developed  internal  data  base  (1992,  p.  234-235) 

Although  Rykroft  and  Kash  contend  that  the  linear  model  is  inadequate  for 
innovating  complex  technology,  they  admit  that  the  non-linear  and  dynamic 
system  is  crisis-oriented  and  messy.  They  apply  the  term,  “self-organizing,”  to 
the  description  of  networks  of  leaders,  knowledge  workers,  and  groups  who 
share  risk  and  information  across  organizational  boundaries  (Rykroft  &  Kash, 
1992,  p.  90).  The  second  pillar,  “evolutionary  learning,”  is  the  imperfect  and 
messy  process  of  integrating  and  testing  components  while  applying  knowledge 
to  keep  pace  with  technological  progress  (Rykroft  &  Kash,  1992,  p.  135). 

While  Rykroft  and  Kash  impart  a  conceptual  perspective  on  the 
management  of  complex  products  and  systems,  lansiti  offers  some  best 
practices  for  technology  integration.  Like  most  of  the  authors  mentioned,  he 
subscribes  to  a  systems  approach  as  the  best  means  of  problem  solving  and 
decision-making,  and  he  points  out  that  the  most  important  period  of  a 
technology  integration  project  is  during  project  specification.  During  this  stage, 
he  accentuates  the  importance  of  a  broad  and  informed  approach  to  framing 
problems  and  searching  for  solutions  through  multiple  contexts  (lansiti,  1995,  p. 
525). 

Several  authors  emphasized  the  crisis-oriented  approach  to  the 
development  of  complex  products  and  systems.  While  the  non-linear  approach 
may  cut  down  on  cycle-time,  it  requires  several  critical  inputs  such  as  a  high 
degree  of  trust  among  organizations,  risk  acceptance,  and  capturing  and 
disseminating  knowledge  to  stakeholders  in  a  timely  manner.  The  next  section 
highlights  several  of  the  potential  problem  areas  that  programs  encounter  when 
they  manage  complex  systems  using  a  non-linear  approach. 
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2.  Common  Managerial  Problems  with  Complex  Programs 

In  his  article  Managing  Innovation  in  Complex  Product  Systems,  Howard 
Rush  (1997)  identified  three  “hotspot”  categories:  1)  requirements  identification, 
2)  coordination  of  information,  and  3)  process  issues  (p.  4/2).  The  considerable 
time  pressures  that  differentiate  complex  products  and  systems  often  lead  to 
inadequate  system  requirements  that  necessitate  later  revision.  The  intensity  of 
organizational  coordination  in  complex  products  and  systems  also  requires  the 
diffusion  of  explicit  and  tacit  knowledge — a  typical  coordination  issue.  Another 
problem  that  permeated  these  types  of  programs  is  the  lack  of  adequate  staffing 
due  to  the  exigent  nature  of  the  program’s  formation.  The  lack  of  staffing  is  a 
potential  cause  of  short  cuts  taken  in  processes  and  best  practices  (Rush,  1997). 

Although  several  of  the  authors  advocated  following  a  less  linear  and 
sequential  model  of  development  for  complex  products  and  systems,  they  all 
advocated  following  some  type  of  process.  Nelson  P.  Repenning  (2001) 
discusses  the  potential  impact  of  not  following  a  process  during  new  product 
development  in  his  paper  Understanding  Fire  Fighting  in  New  Product 
Development.  In  the  context  of  product  development,  Repenning  describes  fire 
fighting  as  the  “unplanned  allocation  of  engineers  and  other  resources  to  fix 
problems  discovered  late  in  a  product’s  development  cycle”  (2001,  p.  5).  He 
believes  that  dedicating  a  large  number  of  resources  to  fighting  fires  takes  away 
valuable  resources  from  other  critical  project  activities.  He  attributes  the 
persistent  fire  fighting  mentality  to  organizations  that  do  not  possess  an  in-house 
capability  for  organizational  learning.  These  organizations  also  fail  to  allocate 
resources,  and  they  attribute  the  cause  of  their  problems  to  the  “attitude  and 
disposition  of  the  people  working  within  the  process  rather  than  to  the  structure  of 
the  process  itself”  (Repenning,  2001,  p.  25). 

3.  Applying  the  Systems  Approach 

A  common  theme  in  this  literature  review  is  that  most  complexity  problems 
are  dynamic  in  nature.  “Systems  thinking”  is  a  holistic  approach  to 
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understanding  and  comprehending  the  many  variables  present  in  dynamic 
situations.  Senge  fully  advocates  the  adoption  of  systems  thinking  when  he 
says, 


we  tend  to  focus  on  snapshots  of  isolated  parts  of  the  system,  and 
wonder  why  our  deepest  problems  never  seem  to  get  solved. 
Systems  thinking  is  a  conceptual  framework,  a  body  of  knowledge 
and  tools  that  has  been  developed  over  the  past  fifty  years,  to 
make  the  full  patterns  clearer,  and  to  help  us  see  how  to  change 
them  effectively.  (2007,  p.  7) 

As  a  conceptual  framework,  the  systems  approach  attempts  to  make  sense  of 
systems  that  have  many  interrelated  parts.  During  product  development,  the 
practical  means  of  realizing  the  systems  approach  is  through  the  discipline 
known  as  systems  engineering.  During  the  post-World  War  Two  period,  systems 
engineering  emerged  as  a  means  to  develop  solutions  to  dynamic  problems. 
Systems  engineering  takes  the  insights  gained  from  systems  thinking  “with  an 
orientation  toward  the  engineering  and  analysis  of  technical  systems”  (Blanchard 
&  Fabrycky,  2006,  p.  19). 

The  Institute  for  Electrical  and  Electronics  Engineers  (IEEE)  defines 
systems  engineering  as  “an  interdisciplinary  collaborative  approach  to  derive, 
evolve,  and  verify  a  lifecycle  balanced  solution  which  satisfies  customer 
expectations  and  meets  public  acceptability”  (1994,  p.  11).  The  International 
Council  on  System  Engineering  (INCOSE)  defines  systems  engineering  as 

an  interdisciplinary  approach  and  means  to  enable  the  realization  of 
successful  systems.  It  focuses  on  defining  customer  needs  and 
required  functionality  early  in  the  development  cycle,  documenting 
requirements,  and  then  proceeding  with  design  synthesis  and 
system  validation  while  considering  the  complete  problem.  Systems 
Engineering  considers  both  the  business  and  the  technical  needs  of 
all  customers  with  the  goal  of  providing  a  quality  product  that  meets 
the  user  needs.  (2006,  June,  p.  1.18) 

The  Defense  Acquisition  Guidebook,  defines  systems  engineering  in  this 
way: 
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Systems  engineering  is  the  overarching  process  that  a  program 
team  applies  to  transition  from  a  stated  capability  need  to  an 
operationally  effective  and  suitable  system.  Systems  engineering 
encompasses  the  application  of  systems  engineering  processes 
across  the  acquisition  lifecycle  (adapted  to  each  and  every  phase) 
and  is  intended  to  be  the  integrating  mechanism  for  balanced 
solutions  addressing  capability  needs,  design  considerations  and 
constraints,  as  well  as  limitations  imposed  by  technology,  budget, 
and  schedule.  The  systems  engineering  processes  are  applied 
early  in  concept  definition,  and  then  continuously  throughout  the 
total  lifecycle.  (2008,  p.  4.1) 

The  common  theme  among  these  definitions  is  the  focus  on  meeting  a  user’s 
needs  through  an  interdisciplinary  approach  to  solving  technical  problems  with  a 
lifecycle  orientation. 

In  accordance  with  the  DoD  Directive  5000.1,  The  Defense  Acquisition 
System,  the  use  of  the  systems  engineering  process  is  the  official  policy  of  the 
DoD,  and  it  will  “optimize  system  performance  and  minimize  total  ownership 
costs”  (Under  Secretary  of  Defense  (AT&L),  2003a).  The  DoD  program  manager 
is  empowered  to  develop  a  tailored  systems  engineering  approach  for  a 
particular  program  that  will  integrate  systems  engineering  processes  throughout 
a  product’s  lifecycle. 

4.  Use  of  Risk  Management 

Simon  described  the  difficulty  of  rational  decision-making  under 
uncertainty  when  he  said,  “reasonable  men  reach  reasonable  conclusions  in 
circumstances  where  they  have  no  prospect  of  applying  classical  models  of 
substantive  rationality”  (Simon,  1978,  p.  14).  Complex  programs  that  are  unable 
to  manage  complexity  and  uncertainty  will  quickly  fall  into  a  resource-intensive 
fire-fighting  mode  (Repenning,  2001). 

Complex  programs  must  adapt  to  an  outer  environment  that  consists  of  a 
large  number  of  risk  factors  and  considerations  that  are  interrelated.  Ultimately, 
this  leads  to  an  environment  of  uncertainty  and  ambiguity.  Programs  categorize 
risk  as  either  internal  or  external.  In  the  article,  On  Uncertainty,  Ambiguity,  and 
Complexity  in  Project  Management,  Pich,  Loch  &  DeMeyer  expressed 
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uncertainty  and  ambiguity  in  terms  of  “information  adequacy”  (2002,  p.  1008). 
External  risk  is  more  difficult  to  mitigate  and  often  falls  into  the  category  of 
“unknown-unknowns”  (Pich  et  al. ,  2002,  p.  1019).  Ambiguity  is  an  unknown- 
known,  and  it  occurs  when  a  program  lacks  awareness  of  a  particular  problem 
but  is  able  to  improve  the  availability  of  information  about  the  unknown  through 
the  expenditure  of  resources  (Pich  et  al.,  2002,  1013).  This  is  in  contrast  to 
“unknown-unknowns”  that  exist  and  exert  a  significant  impact  on  complex 
programs  but  are  completely  unforeseen  by  a  program  manager  (Pich  et  al., 
2002,  p.  1019). 

The  proactive  and  consistent  management  of  risk  is  an  essential  element 
of  successful  projects  (PMI,  2004,  240).  The  risk  management  process  assumes 
that  problems  are  recognizable  through  the  early  identification  of  signals  that 
indicate  a  potential  problem.  The  Risk  Management  Guide  for  DoD  Acquisition 
defines  risk  as  “a  measure  of  future  uncertainties  in  achieving  program 
performance  goals  and  objectives  within  defined  cost,  schedule,  and 
performance  constraints”  (DAU,  2006,  August,  p.  1).  Furthermore,  it  organizes 
risk  into  three  components:  1)  a  future  root  cause,  2)  a  probability  or  likelihood, 
and  3)  a  consequence  or  effect  (DAU,  2006,  August,  p.  1).  The  Risk 
Management  Guide  for  DoD  Acquisition  emphasizes  the  use  of  risk  management 
throughout  a  program’s  lifecycle  by  suggesting  a  strong  integration  with  the 
systems  engineering  and  test  and  evaluation  processes.  The  Risk  Management 
Guide  also  identifies  several  common  risk-related  attributes  to  successful 
programs: 

•  Feasible,  stable,  and  well-understood  user  requirements, 
supported  by  leadership/stakeholders,  and  integrated  with 
program  decisions; 

•  A  close  partnership  with  users,  industry,  and  other  stakeholders; 

•  A  planned  risk  management  process  integral  to  the  acquisition 
process,  especially  to  the  technical  planning  (SEP  and  TEMP) 
processes,  and  other  program  related  partnerships; 
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•  Continuous,  event-driven  technical  reviews  to  help  define  a 
program  that  satisfies  the  user’s  needs  within  acceptable  risk; 

•  Identified  risks  and  completed  risk  analyses; 

•  Developed,  resourced,  and  implemented  risk  mitigation  plans; 

•  Acquisition  and  support  strategies  consistent  with  risk  level  and 
risk  mitigation  plans; 

•  Established  thresholds  and  criteria  for  proactively  implementing 
defined  risk  mitigation  plans; 

•  Continuous  and  iterative  assessment  of  risks; 

•  The  risk  analysis  function  independent  from  the  PM; 

•  A  defined  set  of  success  criteria  for  performance,  schedule,  and 
cost  elements  and  a  formally  documented  risk  management 
process.  (DAU,  August,  2006,  p.  5) 

Every  program  has  some  element  of  risk  whether  they  know  it  or  not,  and 
it  is  the  basic  responsibility  of  any  manager  of  a  complex  program  to  manage 
risk.  A  major  determinant  to  a  program  manager’s  ability  to  manage  risk  is  the 
program’s  strategic  approach. 

5.  Strategic  Planning 

Complex  programs  require  a  significant  degree  of  coordination  and 
synchronization  to  achieve  their  objectives  and  overcome  ill-structured  problems. 
Approaching  ill-structured  problems  requires  the  program  manager  (PM)  to 
engage  in  a  process  known  as  strategic  planning.  Simon  (1976)  described 
strategy  as  a  “time  binding”  process  in  which  “a  series  of  decisions  determine 
behavior  over  a  certain  stretch  of  time”  (p.  67).  Porter  discussed  strategy  in 
terms  of  different  and  unique  positioning.  He  defined  strategy  as  “the  creation  of 
a  unique  and  valuable  position,  involving  a  different  set  of  activities,”  which 
involves  positioning  a  “tailored  set  of  activities”  (Porter,  1996,  p.  68).  Porter  also 
stated  that  the  “essence  of  strategy  is  choosing  what  not  to  do”  (Porter,  1996,  p. 
70). 
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Porter  emphasized  three  types  of  “fit”  for  an  organization:  1)  simple 
consistency,  2)  reinforcing,  and  3)  optimization  of  effort  (Porter,  1996,  pp.  71-73). 
Consistency  occurs  when  an  organization  communicates  a  common  message 
and  the  organization’s  activities  reflect  a  “single-minded”  approach  to  meeting 
objectives  (Porter,  1996,  p.  71).  The  reinforcement  of  fit  occurs  when  activities 
strengthen  and  build  on  one  another  similar  to  the  manner  in  which  risk 
management  reinforces  systems  engineering  (Porter,  1996,  p.  72).  The 
optimization  of  effort  occurs  when  an  organization’s  activities  are  coordinated 
and  minimize  the  amount  of  wasted  effort.  While  strategies  consist  of  many 
interrelated  activities,  it  is  essential  to  keep  in  mind  that  the  whole  matters  more 
than  the  any  individual  part  (Porter,  1996,  p.  73). 

In  terms  of  complex  acquisition  programs,  the  Defense  Systems 
Management  College  (DSMC)  defines  strategy  as  a  “framework  for  planning, 
organizing,  staffing,  controlling,  and  leading  a  program,”  that  is  designed  to 
“achieve  program  objectives  within  specified  resource  constraints”  (1999,  p.  1-1). 
Programs  also  tailor  strategies  to  the  goals,  objectives  and  customer  or  user 
expectations  with  the  goal  of  achieving  resilience  and  stability  over  time  (Porter, 
1996,  p.  66;  DSMC,  1999,  p.  1-1,  1-2).  Strategy  is  also  a  means  for  program 
leadership  to  set  clear  priorities,  integrate  program  activities,  and  serve  as  a 
decision-making  aid  for  individuals  throughout  the  organization  (Porter,  1996,  p. 
69;  DSMC,  1999,  p.  1-4). 

Specific  to  defense  programs,  there  are  five  characteristics  to  acquisition 
strategy:  1)  realism,  2)  stability,  3)  resource  balance,  4)  flexibility,  and  5) 
managed  risk  (DSMC,  1999,  p.  2-1).  Changes  to  an  acquisition  strategy  often 
result  in  changes  to  a  program’s  overall  risk  level,  and  therefore,  the  project 
leadership  must  flexibly  adjust  the  acquisition  strategy  to  changes  in  the 
environment  (DSMC,  1999,  p.  2-7).  The  acquisition  strategy  should  also  serve 
as  a  guide  for  program  stakeholders  on  how  the  program  will  operate  in  all 
phases  of  a  product’s  lifecycle  (DSMC,  1999,  p.  3-10). 
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D.  CONCLUSION 

The  purpose  of  this  chapter  was  to  provide  a  theoretical  framework  for  this 
case  study,  with  a  focus  on  complexity.  Complex  programs,  particularly  those 
using  a  time-based  strategy  of  fielding,  require  a  unique  set  of  considerations  to 
achieve  success.  The  MGS  clearly  falls  into  the  category  of  a  complex  system, 
and  the  MGS  program  certainly  embraced  a  dynamic  self-organization  to  adapt 
to  the  outside  environment.  The  next  chapter  provides  a  context  to  the  outer 
environment  of  the  Stryker  program. 
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III.  THE  ROAD  TO  STRYKER 


A.  INTRODUCTION 

We  [the  Army]  discovered  that  most  of  our  heavy  equipment,  in  a 
country  that  was  wrestling  to  reestablish  itself  economically,  tore 
their  roads  up  so  badly  that  commerce  could  not  get  through.  And 
then  we  had  to  come  back  in  and  repair  those  roads  (as  cited  in 
Hillen,  2000). 

General  Eric  Shinseki’s  observation  could  describe  any  number  of 
situations  in  Iraq  or  Afghanistan.  However,  General  Shinseki’s  comment 
describes  road  conditions  encountered  in  Bosnia  in  1997.  As  the  Chief  of  Staff  of 
the  Army  (CSA)  from  1999-2003,  it  was  his  responsibility  to  set  the  Army’s 
azimuth  and  ensure  that  the  Army  could  meet  all  of  its  obligations  in  accordance 
with  the  National  Security  Strategy  and  National  Military  Strategy.  For  General 
Shinseki,  the  fundamental  problem  was  to  determine  what  the  Army  should  be 
for  the  next  30  years.  Through  this  exercise,  he  identified  a  clear  capability  gap 
between  the  evolving  strategic  environment  and  the  Army’s  existing  capabilities 
(Hillen,  2000). 

To  close  this  gap,  he  initiated  a  transformational  strategy  for  the  Army  that 
he  anticipated  would  last  from  1999  to  2030.  Sustaining  this  long-term  strategy 
required  a  series  of  incremental  changes  to  provide  “irreversible  momentum” 
(Shinseki,  2003).  Embedded  within  Army  Transformation  was  the 
implementation  of  the  Interim  Force  (renamed  the  Stryker  Brigade  Combat  Team 
in  2002),  which  ultimately  served  as  the  catalyst  and  initial  increment  of  Army 
Transformation  (Shinseki,  2001,  p.  12). 

The  purpose  of  this  chapter  is  to  understand  the  origins  of  the  Mobile  Gun 
System  as  part  of  Stryker.  The  background  includes  a  description  of  the  evolving 
strategic  environment  of  the  1990s,  the  strategy  of  Army  Transformation,  the 
Interim  Force  operational  requirements,  and  the  subsequent  selection  of  the 
materiel  solution  for  the  Interim  Armored  Vehicle  (IAV)  requirement. 
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B.  STRATEGIC  CONTEXT:  AN  UNCERTAIN  AND  VOLATILE 

ENVIRONMENT 

The  end  of  the  Cold  War  brought  an  increase  in  small-scale  contingencies 
that  intensified  the  demand  for  ground-force  commitments.  Fiscally,  the 
decreasing  size  of  defense  budgets  constrained  fiscal  resources  and  forced  a 
more  disciplined  prioritization  of  effort.  Economically,  the  United  States 
experienced  a  prolonged  period  of  growth  that  enabled  an  intensive  investment 
in  private  sector  research  and  development  and  led  to  an  increasingly  integrated 
global  community.  Technologically,  the  availability  of  information  technology  was 
rapidly  improving  the  availability  of  relevant  and  real-time  information.  The  Army 
found  itself  on  a  new  playing  field,  yet  it  still  had  the  same  doctrine,  organization, 
and  culture  from  the  Cold  War  period.  The  next  section  discusses  the  increase 
in  small-scale  contingencies  and  the  Army’s  structural  misalignment. 

1.  A  New  Focus  on  Small-scale  Contingencies 

Throughout  the  1990s,  unpredictable  events  caused  the  United  States  to 
place  the  Army  into  a  number  of  potentially  disastrous  situations  such  as  early 
Desert  Shield  in  1990,  Somalia  in  1993,  Haiti  in  1994,  Bosnia  in  1997,  and 
Kosovo  in  1999.  A  rapid  commitment  of  ground  forces  to  remote  regions 
characterized  these  deployments.  An  example  of  a  potentially  disastrous 
situation  occurred  shortly  after  Iraq’s  invasion  of  Kuwait  in  August  1990.  The 
U.S.  lacked  a  medium  force  that  could  rapidly  respond  to  an  Iraqi  invasion  of 
Saudi  Arabia,  and  it  committed  the  lightly  equipped  82nd  Airborne  Division  as  a 
stopgap  measure.  The  Army  essentially  “held  its  breath”  as  this  unit  secured  the 
border  against  several  divisions  of  Iraqi  armor  until  heavy  U.S.  units  arrived 
(Hillen,  2000).  Several  years  later,  a  company  of  Rangers  incurred  heavy 
casualties  while  operating  without  the  benefit  of  armored  vehicles  in  the 
congested  streets  of  central  Mogadishu.  Soon  thereafter,  the  deployment  of 
heavy  armor,  such  as  M-1  tanks,  to  the  Balkans  was  restricted  due  to  the  narrow 
roads  and  weight-restricted  bridges  in  the  region. 
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Concurrent  with  the  increase  in  small-scale  contingencies  was  the  growing 
prevalence  of  information  technology.  The  availability  of  information  technology 
allowed  sub-national  and  transnational  groups  to  improve  their  ability  to 
communicate  and  coordinate  their  efforts  (Shinseki,  2001,  p.  4).  The  multi-polar 
international  security  environment  was  increasingly  vulnerable  to  the  criminal  and 
terrorist  elements  that  used  asymmetric  tactics  to  achieve  their  limited  objectives. 

These  examples  demonstrated  a  pattern  of  contingency  deployments  to 
geographically  remote  areas  under  uncertain  political  and  operational  conditions. 
During  the  1990s,  United  States  reduced  the  size  of  the  Army  from  781,000  to 
479,426,  despite  the  Army’s  role  as  the  nation’s  primary  “military  to  military 
engagement  tool  for  influencing  policies  and  actions  of  other  nations”  (Shinseki, 
2001,  p.  2).  The  smaller  Army  was  clearly  stretched,  and  its  operational  tempo 
increased  from  one  deployment  every  four  years  to  one  deployment  every 
fourteen  weeks  following  the  collapse  of  the  Berlin  Wall  in  1989  (Shinseki,  2000, 

p.  22). 

General  Shinseki  saw  the  Army’s  contribution  to  stability  as  “peacetime 
engagement,  crisis  management,  deterrence,  and  the  kind  of  rapidly  deployable, 
overwhelming  combat  power  that  enables  such  capabilities”  (Shinseki,  2000,  p. 
22).  His  ladder  of  inference  pointed  towards  an  impending  crisis  on  the  nation’s 
strategic  horizon. 

2.  Dealing  with  Army  Structural  Misalignment 

These  developments  revealed  a  structural  gap  in  the  Army’s  capabilities. 
Simply  put,  the  Army  organized  itself  for  either  “high-end”  or  “low-end”  conflict 
(Shinseki,  2000,  p.  23).  The  decreasing  emphasis  on  high-intensity  conflict  and 
the  prevalence  of  small-scale  contingencies  urgently  necessitated  a  force 
optimized  for  these  conditions-specifically  a  force  that  fell  in  a  “medium”  range 
between  the  existing  high-  and  low-end  formations. 

Ten  years  after  the  end  of  the  Cold  War,  the  Army  retained  a  mix  of  heavy 
and  light  “Legacy”  formations  that  it  organized  on  the  Cold  War  paradigm.  The 
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light  formations  were  capable  of  rapid  deployment,  but  they  lacked  sufficient 
lethality,  survivability,  and  mobility  to  engage  a  more  heavily  equipped  adversary. 
On  the  other  hand,  the  heavy  formations  were  extremely  lethal  and  survivable, 
but  they  depended  on  enormous  transportation  assets  that  required  well- 
developed  airfields  and  seaports  at  the  destination  point.  The  Army  lacked  a 
medium  capability  that  could  provide  a  mix  of  heavy  and  light  capabilities.  To 
address  this  urgent  situation,  General  Shinseki  initiated  Army  Transformation. 

C.  THE  VISION:  INITIATE  IRREVERSIBLE  MOMENTUM 

General  Shinseki  was  concerned  that  the  Army  could  potentially  become 
irrelevant  if  it  did  not  adapt  to  the  changing  environment.  Its  current  force 
structure  was  difficult  to  deploy  and,  in  many  ways,  was  a  liability. 

1.  General  Shinseki’s  Ladder  of  Inference 

Recognizing  the  Army’s  shortcomings,  General  Shinseki  initiated  changes 
that  led  to  a  force  that  could  dominate  the  full  spectrum  of  conflict,  not  just  the 
high  and  low  ends.  He  saw  the  next  major  contingency  occurring  in  a  place  like 
Central  Asia  or  East  Timor,  not  the  North  German  Plain.  General  Shinseki 
underscored  how  important  it  was  to  change  the  Army  when  he  stated: 

Frankly,  the  magnificent  army  that  fought  in  Desert  Storm  is  a  great 
army  [...].  But  it  was  one  we  designed  for  the  Cold  War,  and  the 
Cold  War  has  been  over  for  ten  years  now.  As  we  look  forward  to 
the  next  century,  we've  seen  a  bit  of  what  that  next  century  is  going 
to  look  like,  and  the  kinds  of  deployments  we've  had  in  the  last  ten 
years,  (as  cited  in  Hillen,  2000) 

General  Shinseki  was  also  concerned  that  the  Legacy  Forces  were  overly 
dependent  on  predictable  air  and  sea  debarkation  points  that  were  easy  targets 
for  a  future  adversary.  Consequently,  he  made  it  a  requirement  to  insert  an  Army 
brigade  anywhere  in  the  world,  including  austere  airfields,  within  96  hours 
(Shinseki,  2000,  p.  28).  The  end  state  of  the  Army’s  Transformation  was  the 
Objective  Force,  later  known  as  the  Future  Combat  System  (FCS).  Through 
Army  Transformation,  the  Objective  Force  would  be  operational  starting  around 
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2010.  To  hedge  the  capability  gap,  General  Shinseki  modernized  the  Legacy 
Forces,  and  created  the  Interim  Force.  General  Shinseki’s  ladder  of  inference 
created  a  tremendous  sense  of  urgency  for  change.  The  ladder  of  inference 
forced  him  to  confront  the  brutal  fact  that  the  Army  faced  potential  irrelevance  if  it 
did  not  close  the  medium-force  capability  gap  (see  Figure  2). 
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Figure  2.  The  Urgency  Behind  the  Interim  Force  Caused  by  the  Medium- 

force  Capability  Gap 


2.  A  Time-Based  Change  Strategy 

The  purpose  of  the  Interim  Force  was  to  serve  as  the  bridge  between  the 
current  capabilities  and  the  Objective  Force.  The  Interim  Force  would  provide 
the  medium-force  capability,  as  well  as  insights  on  doctrine,  organization,  and 
technology  for  the  Objective  Force  (Shinseki,  2000,  p.  28).  The  Interim  Force 
was  also  the  vital  link  for  General  Shinseki’s  change  strategy,  and  he  placed 
command  emphasis  on  its  urgency.  With  a  four-year  time  horizon  as  the  CSA, 
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General  Shinseki  understood  that  the  Interim  Force  concept  was  the  foothold  for 
Army  Transformation.  In  a  later  interview  with  PBS  Frontline,  General  Shinseki 
said, 

In  my  case,  the  appointment  is  for  four  years.  As  I've  looked  back 
at  the  tenures  of  other  chiefs,  generally  the  good  ideas  that  found 
their  way  into  implementation  are  the  ones  that  were  begun  early 
[...].  I  just  believe  that  I've  got  to  get  the  momentum  early.  That’s 
important  to  transformation,  and  my  contribution  to  wherever 
transformation  ends  up  happening  is  providing  that  momentum  so 
that  future  chiefs  can  build  on  it  [...].  Generally,  it’s  the  first  two 
years  that’ll  make  the  difference,  (as  cited  in  Hillen,  2000) 

The  urgent  nature  of  the  capability  gap  necessitated  the  selection  of  an 
Interim  Armored  Vehicle  (IAV)  that  was  immediately  available.  The  urgent  nature 
of  the  threat  and  his  ability  to  transform  the  military  necessitated  the  adoption  of 
a  time-based  transformation  strategy.  General  Shinseki  stipulated  that  this 
vehicle  be  an  “off-the-shelf  system”  for  procurement  in  FY2000  (Shinseki,  2001, 
p.  12).  According  to  Lieutenant  General  Paul  J.  Kern,  the  Military  Deputy  to  the 
Assistant  Secretary  of  the  Army  for  Acquisition,  Technology  and  Logistics  at  the 
time  of  the  IAV  selection,  General  Shinseki  continuously  pushed  the  Army  to 
move  faster  with  the  selection  of  the  materiel  solution  for  the  IBCT  (Federal  News 
Service,  2000). 

Furthermore,  General  Shinseki’s  four-year  time  horizon  as  the  Chief  of 
Staff  of  the  Army  played  a  critical  role  in  driving  the  IAV  schedule,  and  he 
provided  highly  detailed  direction  over  decisions  that  might  have  an  impact  on  its 
success.  This  oversight  included  the  review  and  approval  of  the  IAV  Request  for 
Proposal  (RFP)  (Baumgardner,  2000,  April  7). 

General  Shinseki’s  time  horizon  as  the  CSA  acted  as  the  upper  parameter 
for  the  Mobile  Gun  System’s  development  schedule.  Within  the  IAV  Source 
Selection  Plan,  originally  published  in  March  2000,  the  time  for  those  vehicles 
requiring  “extended  variant/configuration  development”  was  not  to  exceed  24 
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months,  which  included  government  testing  (Kern,  2000).  In  effect,  the 
developmental  strategy  for  the  MGS  was  time-based,  not  event-based,  from  the 
very  beginning. 

The  intent  of  the  Interim  Force  concept  was  to  have  a  combat  formation 
that  was  packaged  at  the  Aerial  Point  of  Embarkation  (APOE)  and  immediately 
available  for  operations  upon  arriving  at  its  destination  (PM  BCT,  2000,  p.  11). 
That  capability  provided  the  Army  with  a  unique  ability  to  place  a  large,  well- 
equipped  force  deep  into  a  threat  environment.  The  Interim  Force  could  use 
operational  maneuver  to  go  where  it  was  least  expected  while  having  the 
capability  to  sustain  itself  and  fight.  General  Shinseki,  however,  had  a  holistic 
view  of  Transformation,  and  it  clearly  encompassed  more  than  just  a  new 
vehicle.  He  said: 

As  we  talk  about  transformation,  we  intend  to  get  into  the  design  of 
our  units  [...].  As  we  reduce  the  size  of  our  platforms,  we  also 
reduce  the  size  of  this  rather  significant  logistical  footprint,  and  that 
gives  us  the  kind  of  agility  that  will  put  us  in  places  that  are  least 
expected.  We  can  reduce  our  predictability  and  get  in  there  faster. 

(as  cited  in  Hillen,  2000) 

His  approach  was  highly  aggressive,  with  an  IAV  procurement  starting  in 
FY2000  and  an  initial  operational  capability  by  FY2002.  The  unique  Interim 
Force  requirements  also  reflected  a  change  in  the  way  that  the  government 
approached  acquisition  programs. 

D.  ACQUISITION  REFORMS  OF  THE  1990s 

The  IAV  program  was  among  the  vanguard  of  programs  in  the 
government’s  effort  to  revamp  and  streamline  defense  acquisition.  During  the 
1990s,  the  government  passed  a  series  of  legislative  reforms  with  the  intention  of 
aligning  defense  acquisitions  with  the  market-based  model  found  in  the 
commercial  sector.  The  driver  of  these  changes,  Dr.  William  J.  Perry,  the 
Secretary  of  Defense  from  1994-1997,  wanted  to  access  commercial  industry, 
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move  away  from  a  separate  defense  industry,  achieve  near-term  cost  savings, 
and  capitalize  on  the  technology  advances  of  the  commercial  sector  (“DoD  News 
Briefing,”  1995). 

The  primary  components  of  the  legislative  reform  of  the  government’s 
acquisition  system  were  the  Federal  Acquisition  Reform  Act  (FARA),  the  Federal 
Acquisition  Streamlining  Act  (FASA),  and  the  Services  Acquisition  Reform  Act 
(SARA).  The  streamlining  of  government  acquisition  regulations  also  allowed  for 
a  considerable  downsizing  of  the  government’s  civilian  acquisition  workforce. 

1.  Use  of  Performance  Specifications  over  Government 
Specifications  and  Standards 

One  of  the  more  significant  elements  of  these  acquisition  reforms  that 
affected  the  IAV  program  was  the  reduction  or  elimination  in  processes  for 
specifications  and  standards.  Previously,  the  government  relied  on  a  wide  range 
of  military  specifications  (MilSpec)  and  military  standards  (MilStd)  to  guide  the 
contractor  on  what  processes  and  materiel  to  use  in  developing  and  producing  a 
system.  The  Defense  Standardization  Program  Policies  and  Procedures  ( DoD 
4120.24-M)  defines  a  defense  specification  as  “a  document  that  describes  the 
essential  technical  requirements  for  purchased  materiel  that  is  military  unique  or 
substantially  modified  commercial  items”  (Under  Secretary  of  Defense  (AT&L), 
2000,  67). 

The  purpose  of  the  specification  and  standards  reform  movement  was  to 
allow  the  contractor  to  exercise  more  initiative,  infuse  innovation  into  product 
development,  and  shift  to  a  performance-based  specification.  In  relinquishing 
some  elements  of  design-oversight  and  allowing  the  commercial  sector  to  find 
the  materiel  solution,  the  challenge  for  the  government  was  how  to  “clearly 
describe  technical  requirements  and  provide  sufficient  verification  to  assure  that 
products  meet  the  users’  needs”  (Millett  &  Gillis,  1998,  p.  72). 
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2.  Use  of  Non-Developmental  Items  (NDI)  and  Commercial  Off- 
the-Shelf  (COTS) 

With  a  drive  for  a  peace  dividend  following  the  end  of  the  Cold  War,  the 
DoD  had  fewer  funds  available  for  research  and  development.  The  decrease  in 
research  and  development  funding  required  the  DoD  to  look  towards  the  private 
sector  for  products  and  services  that  were  immediately  available.  The  DoD 
termed  these  items  as  either  Non-Development  Items  (NDI)  or  Commercial  Off- 
the-Shelf  (COTS). 

In  a  June  2000  report,  the  Office  of  the  Secretary  of  Defense  (OSD) 
provided  a  list  of  best  practices  and  lessons  learned  for  NDI  and  COTS.  The 
report  defined  a  COTS  item  as: 

one  that  is  sold,  leased,  or  licensed  to  the  general  public;  offered  by 
a  vendor  trying  to  profit  from  it;  supported  and  evolved  by  the 
vendor  who  retains  the  intellectual  property  rights;  available  in 
multiple,  identical  copies;  and  used  without  modification  of  the 
internals.  (Gansler,  2000,  July,  p.  3) 

The  DoD  aggressively  pushed  to  maximize  the  use  of  COTS  and  NDI  to  reduce 
cycle-time,  increase  the  pace  of  new  technology  insertion,  improve  reliability  and 
availability,  and  lower  the  total  lifecycle  costs  (Gansler,  2000,  July,  p.  2).  COTS 
are  a  subset  of  NDI  and  are  defined  as: 

Items  that  are  used  exclusively  for  government  purposes  by  a 
Federal  Agency,  a  state  or  local  government,  or  a  foreign 
government  with  which  the  United  States  has  a  mutual  defense 
cooperation  agreement;  and  any  item  described  here  that  requires 
only  minor  modifications  of  the  type  customarily  available  in  the 
commercial  marketplace  in  order  to  meet  the  requirements  of  the 
processing  department  or  agency.  (Gutierrez,  2002,  p.  66) 

While  the  intent  of  NDI  and  COTS  was  to  “simplify  and  accelerate  the  acquisition 
process,”  the  use  of  NDI  and  COTS  also  incurred  programmatic  risk  (Steves, 
1997,  p.  40).  Among  the  risks  associated  with  NDI  and  COTS  are  the  1)  form,  fit, 
and  function  characteristics,  2)  ability  to  adapt  interface  and  data  standards,  3) 
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vendor’s  anticipated  and  intended  use  of  the  NDI  and  COTS,  4)  vendor’s  test 
approach,  and  5)  the  government’s  ability  to  verify  vendor  test  results  (Gutierrez, 

2002,  p.  68). 

3.  IAV  Request  for  Proposal  (RFP) 

When  the  IAV  Program  Management  Office  released  the  draft  RFP  in 
December  1999,  it  did  not  contain  detailed  specifications  because  the  program 
manager  wanted  to  provide  the  contractor  with  the  maximum  amount  of  flexibility 
in  tailoring  their  proposals  (Dawson,  2001,  p.  56).  The  final  RFP,  published  in 
April  2000,  contained  a  performance-based  Statement  of  Work  (SOW)  founded 
on  the  Operational  Requirements  Document  (ORD);  it  also  contained  only  seven 
government  specifications  and  standards  (Dawson,  2001,  p.  76,  95).  The  final 
RFP  also  allowed  the  possibility  of  awarding  separate  contracts  for  the  Infantry 
Carrier  Variant  (ICV)  and  for  the  Mobile  Gun  System  variant  (Baumgardner, 
2000,  April  10).  The  government  presented  four  alternatives  for  contract  awards 
in  the  RFP:  1)  one  award  for  the  ICV  variants  and  MGS  variant,  2)  one  award  for 
ICV  variants  and  one  award  for  the  MGS,  3)  one  award  for  the  ICV  variants  only, 
or  4)  one  award  for  the  MGS  only  (Gamboa,  2001 ,  April  9,  4). 

Working  closely  with  the  materiel  developer,  the  Training  and  Doctrine 
Command  (TRADOC)  conducted  a  parallel  effort  to  develop  the  operational 
requirements.  Although  the  government  could  request  a  waiver  to  use  military 
specifications  and  standards  through  the  Milestone  Decision  Authority  (MDA),  the 
waiver  process  was  long  and  generally  discouraging  because  the  DoD  was  trying 
to  move  away  from  the  old  ways  of  doing  business.  It  was  not  until  2005  that  the 
DoD  eliminated  the  waiver  policy  to  increase  the  program  manager’s  flexibility  to 
cite  military  specifications  and  standards  within  a  solicitation  or  contract  (Kratz, 
2005). 

E.  A  NEW  APPROACH:  INTERIM  FORCE  REQUIREMENTS 

The  Interim  Force  requirements  reflected  the  ambiguous  and  uncertain 

threat  model  of  the  21st  century.  The  Army  chose  a  new  and  innovative  path  to 
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the  Interim  Force  when  it  transitioned  from  a  threat-based  to  a  unit-based 
approach  to  requirements.  The  next  section  discusses  the  transition  of 
requirements  concepts,  the  Stryker  operational  tenets,  and  the  source  selection. 

1.  Transition  from  Threat-based  to  Unit-based  Requirements 

In  previous  armored  vehicle  acquisitions,  the  Army  developed 
requirements  based  on  a  clearly  defined  threat.  During  the  Cold  War  period,  the 
Army  could  draw  on  abundant  amounts  of  information  about  known  threat 
systems.  For  instance,  the  Army  developed  the  requirements  for  the  M-1 
Abrams  Tank  and  the  M-2  Bradley  Fighting  Vehicle  to  counter  a  known  spectrum 
of  Warsaw  Pact  platforms  and  tactics.  Although  both  vehicles  functioned  as  part 
of  a  combined  arms  team,  the  Army  did  not  stipulate  a  requirement  for 
commonality.  Additionally,  these  systems  went  through  a  deliberate  systems 
development  process  that  included  several  iterations  of  technology  insertion 
(COL  Robert  Schumitz,  PM  SBCT,  personal  communication,  January  29,  2009). 
The  Interim  Armored  Vehicle  (IAV)  was  the  Army’s  first  new  armored  combat 
vehicle  since  1981,  and  the  Army  saw  an  opportunity  to  improve  efficiency  and 
effectiveness  with  a  new  approach  (Federal  News  Service,  2000). 

The  Army  designed  a  new  type  of  brigade  from  the  ground  up  that  it 
designated  as  the  Interim  Brigade  Combat  Team  (IBCT).  The  Army  intended  for 
the  Interim  Armored  Vehicle  (IAV)  to  serve  as  the  common  vehicle  platform  to 
meet  the  unit’s  holistic  requirements.  The  requirements  for  the  Stryker  were 
captured  in  the  Operational  Requirements  Document,  written  by  the  user 
community  and  describing  the  system’s  intended  mission  and  the  anticipated 
operational  and  sustainment  concepts.  The  Medium  Armored  Vehicle 
Operational  Requirements  Document  (ORD)  broadly  described  the  threat  in  this 
way: 

Asymmetric  warfare  focuses  whatever  may  be  one  side’s 
comparative  advantage  against  an  enemy’s  relative  weakness.  A 
defining  and  distinguishing  aim  of  asymmetric  warfare  is  the 
creation  of  conditions  where  the  enemy’s  relative  advantage  cannot 
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be  applied  is  degraded  or  neutralized  [sic].  The  IBCT  [Interim 
Brigade  Combat  Team]  will  be  employed  worldwide,  wherever  US 
interests  are  threatened.  To  this  end,  potential  threat  forces  will  be 
armed  with  various  mixes  of  increasingly  sophisticated  weaponry. 
(Federation  of  American  Scientists,  2000) 

The  Army  determined  that  it  wanted  a  medium  unit  capability  that  could  function 
in  the  both  the  “full  spectrum  environment”  and  small-scale  contingencies 
(Federation  of  American  Scientists,  2000).  Upon  achieving  its  full  operation 
capability,  the  Interim  Force  would  prevent  the  Army  from  becoming  irrelevant 
through  the  ability  to  insert  a  “credible  combat  force  on  the  ground  anywhere  in 
the  world  in  96  hours  from  liftoff”  (Panel  on  Operational  Test  Design  and 
Evaluation  of  the  Interim  Armored  Vehicle,  2004,  p.  1 17). 

2.  Interim  Brigade  Combat  Team  (IBCT)  Operational  Concept 

The  ORD  for  the  Stryker  defines  the  top-level  operational  capabilities 
desired  for  the  IBCT  as  well  as  the  system-level  capabilities  for  the  IAV  itself 
(Panel  on  Operational  Test  Design  and  Evaluation  of  the  Interim  Armored 
Vehicle,  2004,  p.  1 1 7).  The  ORD  describes  the  top-level  capabilities  of  the  IBCT : 

As  a  full  spectrum  combat  force,  the  IBCT  is  capable  of  conducting 
all  major  doctrinal  operations  including  offensive,  defensive, 
stability,  and  support  actions.  Its  core  operational  capabilities  rest 
upon  excellent  operational  and  tactical  mobility,  enhanced 
situational  understanding,  combined  arms  integration  down  to  the 
company  level,  and  high  dismount  strengths  for  close  combat  in 
urban  and  complex  terrain.  Properly  integrated  through  a  mobile 
robust  C4ISR  network,  these  core  capabilities  compensate  for 
platform  limitations  that  may  exist  in  the  close  fight,  leading  to 
enhanced  force  effectiveness.  When  employed  in  the  operational 
environment  for  which  it  is  optimized,  the  IBCT  has  the  capability  to 
achieve  decision  as  a  result  of  its  early  entry,  shaping,  and  decisive 
actions.  (Federation  of  American  Scientists,  2000) 

The  ORD  describes  the  combined  arms  approach  of  the  IBCT  and  its  maneuver 
advantages.  Unlike  the  Legacy  Forces,  the  Army  intended  for  the  IBCT  to  be  in 
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a  combat  configuration  prior  to  leaving  its  air  or  sea  embarkation  point.  Upon 
arrival  in  an  area  of  operations,  the  Army  wanted  the  IBCT  prepared  for 
immediate  combat  operations. 

The  Army  planned  for  each  of  the  pieces  and  parts  of  the  IBCT  to  operate 
together  for  a  holistic  capability  with  a  focus  on  the  company  level.  For  the  user 
community,  this  point  is  essential  because  the  IBCT  is  a  system-of-systems. 
Although  each  of  the  systems  can  operate  individually,  when  combined  they 
have  a  decisive  effect  through  their  constellation  of  capabilities.  The  ORD 
discusses  the  six  Key  Performance  Parameters  (KPPs)  that  serve  as  the 
performance  drivers  for  the  IBCT.  KPPs  are: 

Those  attributes  or  characteristics  of  a  system  that  are  considered 
critical  or  essential  to  the  development  of  an  effective  military 
capability  and  those  attributes  that  make  a  significant  contribution 
to  the  characteristics  of  the  future  joint  force  as  defined  in  the 
Capstone  Concept  for  Joint  Operations  (Chairman  of  the  Joint 
Chief  of  Staff,  2007a,  May  1 ,  p.  GL-1 4). 

These  KPPs  provide  metrics  in  terms  of  threshold  and  objective  values.  The 
Acquisition  Strategy  Report  for  the  Interim  Armored  Vehicle  listed  four  KPPs: 

•  Interoperability — possesses  an  interoperable  capability  to  host  and 
integrate  existing  and  planned  C4ISR  systems. 

•  C-130  transportability — be  transportable  in  a  C-130  aircraft. 

•  Infantry/Engineer  Squad — be  capable  of  transporting  and 
protecting  a  9-man  infantry  or  engineer  squad. 

•  Mobile  Gun  System  Bunker  Buster — serves  primarily  as  a  bunker 
buster,  not  as  an  anti-tank  platform.  (PM  BCT,  2000,  p.  14) 

The  Army  developed  the  Interim  Force  KPPs  as  the  critical  requirements  for  a 
family  of  vehicles  that  complement  one  another.  The  family  of  vehicles  includes 
ten  variants,  and  the  IBCT  requires  each  of  these  variants  to  achieve  its  full 
capability  (see  Figure  3). 
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Interim  Armored  Vehicle  Variants 


Commancer's  Vehicle 
(CV)  -  28 


Fire  Support  Vehicle 
(FSV)- 14 


Infantry  Caiier  Vehicle 
(ICV)-  130 


Commonality 


Mobile  Gun  System 
(MGS)  -  29 


Common  Operating  Picture 


Reconnaissance  Vehicle 

Common  Chassis  &  Drive  Train 
Common  K.PP's 

NBC  Reconnaissance 

<RV>-  52 

Common  Survivability 

Vehicle  (NBCRV)-  3 

Common  TMDE,  Spare  Parts, 
Tools  &  Skills 


Medical  Evacuation  Vehicle 
(MEV)-  16 


120mm  Mounted 
Mortar  Carrier  (MCVi  -  37 


Engineer  Squad  Vehicle 

Anti  Tank  Guided  Missile 

(ESV)  -  13 

(ATGM)  -  10 

Figure  3.  Interim  Armored  Vehicle  Variants  (From  McCarroll,  original 

chart  modified,  2008,  slide  4) 


F.  IAV  ACQUISITION  STRATEGY 

In  accordance  with  DoD  Instruction  5000.2,  all  acquisition  programs 
require  an  approved  acquisition  strategy  upon  program  initiation  (DAU,  2008,  p. 
2.3).  The  acquisition  strategy  uses  a  total  systems  approach  that  takes  into 
account  all  activities  that  will  occur  throughout  the  program’s  lifecycle  (DAU, 
2008,  p.  2.3).  The  program  manager  is  responsible  for  preparing  the  acquisition 
strategy  and  tailoring  it  to  the  program’s  specific  needs  and  constraints. 
Additionally,  the  acquisition  strategy  serves  as  a  decision  aid  by 

prioritizing  and  integrating  many  diverse  functional  requirements, 
evaluating  and  selecting  important  issue  alternatives,  identifying  the 
opportunities  and  times  for  critical  decisions,  and  providing  a 
coordinated  approach  to  the  economical  and  effective  achievement 
of  program  objectives.  (DAU,  2003,  p.  1-4) 
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The  Army  adopted  an  IAV  acquisition  strategy  that  fully  supported  General 
Shinseki’s  charter  for  a  rapidly  fielded  medium  force  that  could  provide  strategic 
responsiveness.  In  accordance  with  General  Shinseki’s  guidance  for  the  Interim 
Force,  the  ORD  states  that: 

The  initial  IBCTs  will  be  populated  with  systems  consisting  of 
integrated  off-the-shelf  capabilities.  Combined  with  these  off-the- 
shelf  systems,  innovative  applications  will  enable  full  operational 
capabilities  for  the  interim  force.  (Federation  of  American  Scientists, 

2000) 

The  IAV  acquisition  strategy  was  unique  in  that  it  covered  both 
developmental  and  non-developmental  efforts.  For  programs  that  involve 
development,  a  technology  development  acquisition  strategy  is  normally  used.  In 
accordance  with  the  Defense  Acquisition  Guidebook,  the  technology 
development  acquisition  strategy  discusses  the  management  of  research  and 
development,  the  number  of  prototypes,  the  use  of  the  prototypes  in  testing,  and 
specific  decision  points  for  the  user  and  materiel  developer  to  determine  the 
maturity  of  a  system  under  development  (DAU,  2008,  p.  2.3). 

1.  Evolutionary  Approach 

The  Army  used  an  acquisition  strategy  that  required  the  use  of  NDI  to 
allow  for  rapid  fielding  while  avoiding  any  type  of  long  system  development. 
Additionally,  the  acquisition  strategy  attempted  to  execute  activities  such  as 
“development,  production,  testing,  fielding,  deployment,  and  sustainment”  in  a 
concurrent  rather  than  sequential  manner  (PM  SBCT,  2006,  March,  p.  1).  The 
IAV  acquisition  strategy  adopted  an  evolutionary  acquisition  approach.  The  DoD 
5000.2,  The  Operation  of  the  Defense  Acquisition  System  defines  evolutionary 
acquisition  as: 

the  preferred  DoD  strategy  for  rapid  acquisition  of  mature 
technology  for  the  user.  An  evolutionary  approach  delivers 
capability  in  increments,  recognizing,  up  front,  the  need  for  future 
capability  improvements.  The  objective  is  to  balance  needs  and 
available  capability  with  resources,  and  to  put  capability  into  the 
hands  of  the  user  quickly.  The  success  of  the  strategy  depends  on 
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consistent  and  continuous  definition  of  requirements,  and  the 
maturation  of  technologies  that  lead  to  disciplined  development  and 
production  of  systems  that  provide  increasing  capability  towards  a 
materiel  concept.  (Under  Secretary  of  Defense  (AT&L),  2003b,  p.  4) 

The  evolutionary  approach  aimed  to  provide  continuous,  preplanned 
improvements  to  meet  current  and  future  capability  gaps  as  technology  matured 
(DAU,  2008,  p.  2.3.2).  The  Acquisition  Strategy  Report  for  the  Interim  Armored 
Vehicle  stated  the  following  objectives: 

•  Emphasize  rapid  acquisition, 

•  Incorporate  time-phased  requirements  as  appropriate, 

•  Integrated  acquisition  and  logistics, 

•  Stress  interoperability  of  the  lAVs  within  and  outside  the  BCT, 

•  Incorporate  Cost  as  an  Independent  Variable  (CAIV), 

•  Integrate  test  and  evaluation  throughout  the  process  rather  than  as  a 
final  exam, 

•  Focus  on  better  performance  with  lower  costs  and  not  just  on  lower 
costs, 

•  Stress  that  system  performance  should  also  consider  better  reliability 
and  quality,  and 

•  Investigate  and  incorporate  technology  as  appropriate  throughout  the 
lifecycle.  (PM  BCT,  2000,  pp.  10-11) 

The  program  initially  used  the  March  1996,  DoD-lnstruction-5000.2R 
acquisition  structure  with  a  Milestone  I  to  III;  PM  SBCT  kept  this  structure  for  the 
MGS  and  NBCRV  until  those  programs  reached  their  Milestone  III  (PM  SBCT, 
2006,  March,  p.  5)  (see  Figure  4). 
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Figure  4.  DoD  Program  Lifecycle  Models  (From  PM  SBCT,  2006,  March, 

P-6) 


2.  Risk  Management 

The  Defense  Acquisition  Guidebook  defines  risk  management  as  “the 
overarching  process  that  encompasses  identification,  analysis,  mitigation 
planning,  mitigation  plan  implementation,  and  tracking”  (DAU,  2008,  p.  4. 2. 3. 5). 
Additionally,  risk  management  is  most  effective  when  the  program  manager 
integrates  it  with  a  program’s  systems  engineering  process  “as  a  driver  and  a 
dependency  on  those  processes  for  root  cause  and  consequence  management” 
(DAU,  2008,  p.  4. 2. 3. 5).  The  IAV  acquisition  strategy  highlighted  four  areas  of 
risk  for  the  program. 

For  schedule  risk,  the  acquisition  strategy  discussed  the  high  probability 
for  “development,  test,  and  production  lead  times  for  the  MGS”  with  an  initial 
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assessment  of  red  (PM  BCT,  2000,  p.  23).  The  program  manager’s  mitigation 
plan  for  the  MGS  development  risk  was  to  substitute  suitable  in  lieu  of  systems 
until  the  MGS  was  available  (PM  BCT,  2000,  p.  23). 

For  technical  risk,  the  acquisition  strategy  discussed  the  potential 
integration  issues  for  the  ICV  variants  with  a  low  probability  of  occurrence  (PM 
BCT,  2000,  p.  24).  With  regard  to  the  ICV,  the  PM  accepted  the  technical  risk. 

G.  THE  MATERIEL  SOLUTION  FOR  THE  IBCT 

Market  research  began  in  earnest  with  the  Platform  Performance 
Demonstration  (PPD)  held  at  Fort  Knox,  Kentucky  from  December  1999  to 
January  2000.  During  the  PPD,  the  Army  hosted  35  candidate  platforms  from  1 1 
different  contractors  (Steele,  2000,  March,  p.  24).  The  purpose  of  the  PPD  was 
to  “determine  the  potential  availability  of  a  family  or  families  of  systems  to  equip  a 
new  brigade  organization  designed  for  full  spectrum  operations”  (Bell,  November 

18,  p.  1). 

The  PPD  served  as  a  market  survey  for  the  Army,  not  as  a  competition. 
Given  the  NDI  acquisition  strategy,  the  PPD  also  provided  insights  on  the 
development  of  the  Operational  &  Organizational  Concept  and  the  overarching 
requirements  document.  The  Army  also  used  it  to  “evaluate  existing  systems  to 
determine  the  state  of  the  art,  and  see  if  the  performance  envisioned  for  the 
interim  brigades  was  achievable”  (PM  BCT,  2000,  p.  5).  At  the  close  of  the  PPD, 
the  Army  provided  each  contractor  with  a  written  report  of  their  vehicle’s  potential 
problem  areas  (Bell,  November  18,  p.  3).  During  the  PPD,  Major  General  B.B. 
Bell,  the  Armor  Center’s  commanding  general  at  the  time,  clarified  that  the  PPD 
was  not  part  of  the  formal  competitive  process  and  that  the  Army  was  open  to 
both  wheeled  and  tracked  drivetrains  (Steele,  2000,  March,  p.  24). 

During  the  PPD,  several  companies  marketed  their  designs  for  the  MGS 
requirement  for  the  IBCT.  United  Defense  marketed  its  M-8  Armored  Gun 
System,  a  tracked  vehicle  that  it  developed  in  the  early  1990s  to  meet  an 
armored  reconnaissance  vehicle  requirement  for  the  82nd  Airborne  Division. 

Despite  meeting  the  C-130  transportability  requirement  and  being  production 
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ready,  the  Army  cancelled  the  M-8  program  in  1996  because  of  budget 
constraints  (Jane’s  Light  Armored  Vehicles,  2008,  August  13).  General 
Dynamics  Land  Systems  (GDLS)  marketed  their  Light  Armored  Vehicle  (LAV)  III 
with  a  turreted  105mm  gun  that  it  had  previously  used  as  a  demonstrator  for 
international  markets  (LTG  (Ret)  Joseph  Yakovac,  personal  communication, 
December  17,  2008).  The  GDLS  variant  demonstrated  strong  potential,  but  it  did 
not  have  an  auto-loader,  an  integrated  C4ISR  suite,  a  coaxial  machine  gun  or 
commander’s  weapon,  and  fire  control  modifications  to  integrate  the  main  gun 
ammunition  (Gourley,  2003,  May).  All  of  those  components  were  essential  to 
meet  ORD  requirements  for  the  MGS. 

The  PPD  was  a  critical  event  for  developing  Non-Developmental  Item 
(NDI)  assumptions.  The  Army  assumed  that  the  NDI  vehicles  could  achieve  “the 
system  requirements  with  minimal  or  no  modification”  based  on  the  PPD 
observations  (PM  BCT,  2000,  p.  18).  Soon  after  the  PPD,  the  Army  published  a 
Request  for  Proposal  (RFP)  on  February  29,  2000,  and  it  began  a  review  of  the 
contractor’s  platforms.  The  Source  Selection  Authority  (SSA)  for  the  IAV  contract 
was  Lieutenant  General  Paul  J.  Kern.  The  SSA  served  as  the  “sole  authority 
designated  to  direct  the  selection  process  and  make  the  selection  decision” 
(Kern,  2000,  p.  5). 

1 .  Contract  Award  (November  2000) 

Three  months  behind  their  original  schedule,  the  Army  announced  on 
November  16,  2000,  that  the  General  Dynamics  Land  Systems  &  General  Motors 
Limited  Liability  Corporation  (GM/GDLS)  won  the  contract  award  of  the  ACAT  ID 
IAV  vehicle  (Hinton,  2001,  p.  13).  Seven  defense  contractors  had  submitted 
proposals  with  two  contractors,  GM/GDLS  and  UDLP,  submitting  several 
proposals.  The  proposals  were  evaluated  based  on  five  criteria  in  order  of 
importance:  1  &  2)  schedule  and  performance  (equal),  3  &  4)  supportability  and 
cost  (equal),  and  5)  management  (Gamboa,  2001,  April  9,  p.  4).  Within  the 
performance  area,  the  Army  evaluated  a  performance  requirements  element  and 

a  commonality  element;  within  the  supportability  area,  the  Army  evaluated  a 
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deployability  element,  a  sustainment  cost  element,  a  system  maintainability 
element,  and  a  predicted  reliability  element  (Kern,  2000,  p.  9).  Although  there 
were  a  number  of  individual  variants  that  had  superior  performance,  the  Army’s 
desire  for  commonality  took  priority.  Additionally,  commonality  took  priority  over 
other  suitability  factors  such  as  reliability. 

At  the  contract  award  announcement,  LTG  Kern  emphasized  that  he 
selected  General  Dynamics  primarily  because  of  the  performance,  supportability, 
and  commonality  that  it  offered  across  its  ten  variants  (Gamboa,  2001,  April  9,  p. 
7).  This  was  particularly  important  to  the  Army  because  it  decreased  the  IBCT 
sustainment  and  training  requirements.  Additionally,  the  Army  emphasized  the 
GDLS  advantages  in  protection,  vehicle  speed,  and  sustainment  cost. 

The  GM/GDLS  based  their  materiel  solution  on  the  Light  Armored  Vehicle 
(LAV)  III,  an  8  x  8,  wheeled,  armored  vehicle.  GM/GDLS  centered  all  ten 
versions  of  the  IAV  on  the  LAV  III  design,  and  each  had  unique  mission 
equipment  packages.  The  LAV  III  offered  a  common  armored  hull,  suspension, 
power  pack,  drivetrain  and  associated  system  (GDLS,  2002,  p.  5). 

Although  the  MGS  shared  the  basic  chassis  as  the  other  nine  versions, 
the  Army  considered  it  a  separate  variant  because  it  required  additional 
developmental  work.  During  the  award  press  conference  in  November  2000, 
LTG  Kern  stated  that  the  “MGS  will  take  the  longest  [to  develop]  as  it  is  closest  to 
a  full  development”  (Federal  News  Service,  2000).  The  Army  initially  estimated 
that  the  MGS  would  require  approximately  two  years  of  developmental  work, 
based  on  the  GM/GDLS  proposal.  The  Army  acknowledged  that  MGS  would 
require  integration  efforts,  but  it  underplayed  this  by  stating  that  it  did  not  entail 
“new  guns,  sights,  or  sensor  packages  for  this  equipment”  (Federal  News 
Service,  2000).  The  Army  considered  an  extended  developmental  program, 
defined  as  greater  than  24  months,  as  counter  to  the  Army’s  Transformation 
strategy  and  early  fielding  of  Interim  Brigade  Combat  Teams.  Consequently,  the 
Army  urged  each  of  the  offerors  to  consider  carefully  the  “probability  of  success” 
for  meeting  the  24-month  timeline  with  their  variant  proposals  (Kern,  2000,  p.  12). 
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In  this  regard,  LTG  Kern  acknowledged  that  the  GDLS  MGS  schedule  was 
“substantially  inferior”  to  that  of  the  UDLP  variant,  but  he  did  not  view  this  as 
unacceptable  (Gamboa,  2001,  April  9,  p.  7). 

At  the  close  of  the  contract  award  announcement,  LTG  Kern  also  stated 
that  there  was  heavy  pressure  from  higher  authority  to  push  for  a  shorter 
schedule  to  enable  a  full  operational  capability  for  the  Interim  Brigade  Combat 
Team.  He  said: 

you  talk  to  all  of  our  military’s  bosses  in  the  Army,  General 
Shinseki,  [they  say  that]  we’re  too  slow.  This  has  been  a 
remarkable  trip  for  all  of  us,  to  go  from  a  concept  about  a  year  ago. 

From  their  perspective  [they  say],  “we  [materiel  developers]  aren’t 
moving  fast  enough,”  rather  than  “why  didn’t  we  wait.”  We  have  a 
capability,  which  we  are  trying  to  get  to  the  field  as  quickly  as 
possible  because  it  does  not  exist  today.  (Federal  News  Service, 

2000) 

Although  the  tracked  option  proposed  by  United  Defense  offered  an  option  that 
required  little  developmental  work  and  a  faster  schedule  at  a  lower  cost,  the 
Army  made  a  trade-off  based  on  the  limited  amount  of  available  information  from 
the  PPD  and  the  contractor  proposals. 

It  seems  apparent  that  the  Army  intended  to  make  the  best  decision  that  it 
could  with  the  limited  time  and  information  available  rather  than  make  a  perfect 
decision.  Given  the  information  available  from  the  PPD  and  other  market 
research  conducted  by  the  materiel  developer  and  user  communities,  the 
perception  was  that  the  GDLS  variants,  particularly  the  MGS,  could  quickly 
mature.  It  is  also  interesting  to  note  that  within  the  Acquisition  Strategy  Report 
for  the  Interim  Armored  Vehicle,  published  in  March  2000,  the  Army  identified  the 
integration  of  mission  equipment  on  the  ICV  as  the  primary  technical  risk  area 
(PM  BCT,  2000,  p.  24).  Yet  this  report  did  not  discuss  the  technical  risk  of 
integrating  the  more  complex  components  on  the  MGS  or  NBCRV,  both  of  which 
encountered  significant  challenges  with  systems  integration  (PM  BCT,  2000,  p. 
24). 
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2.  Award  Protest 

Soon  after  the  contract  award,  United  Defense,  the  unsuccessful  offeror  of 
the  M-113  ICV  variant  and  the  M-8  AGS  variant,  filed  a  protest.  The  General 
Accounting  Office  upheld  the  decision  to  award  the  contract  to  GM/GDLS,  and  it 
found  that  the  Army’s  selection  of  the  GM/GDLS  ICV  and  MGS  was  reasonable 
(Gamboa,  2001,  April  9,  p.  7).  Within  the  UDLP  award  protest,  there  was 
considerable  discussion  on  system  reliability — a  significant  problem  later 
encountered  with  the  GDLS  MGS.  However,  the  focus  of  the  reliability  debate 
centered  on  the  vehicle  chassis,  not  the  unique  Mission  Equipment  Packages 
(MEP).  It  is  noteworthy  that  the  GDLS  MGS  was  viewed  as  having  significantly 
superior  predicted  reliability  over  the  UDLP  MGS,  mainly  because  the  metric  for 
comparison  was  Mean  Miles  Between  Critical  Failures  (MMBCF).  The  use  of  this 
metric  did  not  truly  address  the  uncertainty  of  the  unproven  Aries  ammunition 
handling  system  (AHS)  that  the  GDLS  MGS  employed. 

The  award  protest  delayed  what  was  already  a  highly  compressed  schedule 
by  126  days,  and  it  slowed  the  program’s  momentum  (Michael  Viggato,  Deputy  PEO 
GCS,  personal  communication,  December  12,  2008).  The  Army  eventually  initiated 
work  on  the  GM/GDLS  contract  on  April  9,  2001  (Hinton,  2001 ,  p.  1 3). 

H.  CONCLUSION 

Despite  the  protest,  the  Army  successfully  initiated  the  first  stage  of  General 
Shinseki’s  plan  for  Army  Transformation.  Less  than  12  months  after  General 
Shinseki  announced  his  vision,  the  Army  conducted  a  series  of  difficult  tasks  that 
included  the  IAV  requirements  document,  PPD  &  market  research,  RFP,  and  source 
selection.  While  not  a  perfect  process,  the  view  was  that  the  Army  could  make 
necessary  adjustments  as  necessary  rather  than  seek  an  optimal  solution  at  the 
expense  of  time. 

The  Army  demonstrated  a  willingness  to  accept  some  development  on  the 
GDLS  version  of  the  MGS  because  of  the  advantages  it  offered  in  commonality 
and  performance.  The  Army  perceived  that  the  GDLS  variant  of  the  MGS  was 
close  to  ready  and  it  was  eager  to  initiate  the  program. 
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IV.  THE  DEVELOPMENT  OF  THE  MOBILE  GUN  SYSTEM 


A.  INTRODUCTION 

As  one  of  the  Army’s  top  acquisition  priorities,  the  Stryker  had  the  full 
support  of  the  Army’s  senior  leadership  as  well  as  dedicated  fiscal  resources,  but 
it  also  faced  the  pressures  of  a  time-based  acquisition  strategy.  Unlike  other 
programs,  the  Stryker  consisted  of  both  developmental  and  non-developmental 
variants  that  were  under  the  same  acquisition  strategy. 

The  Army  immediately  fielded  eight  of  the  Stryker’s  variants,  while  two 
variants  required  additional  development  (MGS  and  NBCRV).  The  Army  knew 
that  these  platforms  required  the  integration  of  multiple  components,  and  they 
were  operating  under  the  assumption  that  the  MGS  would  require  approximately 
two  years  to  field  (Federal  News  Service,  2000).  At  the  time  of  the  contract 
award  announcement,  this  meant  that  the  MGS  would  complete  its  development 
in  July  2003. 

Coincidentally,  this  was  the  same  time  that  the  Stryker’s  “product 
champion,”  General  Eric  Shinseki,  would  end  his  four-year  tenure  as  the  Army’s 
Chief  of  Staff.  Although  this  two-year  estimate  proved  to  be  unachievable,  it 
provided  a  sense  of  urgency  to  the  program.  The  Army  continued  to  push  for  the 
rapid  development  of  the  MGS  because  it  deemed  the  MGS  as  “critical”  to 
meeting  the  expectations  of  the  combatant  commanders  (Schuster,  2002,  May, 
p.  19). 

As  one  of  the  two  developmental  variants,  the  MGS  encountered  a  series 
of  unique  challenges;  this  chapter  provides  an  overview  of  the  MGS 
development.  The  chapter  discusses  the  MGS  EMD  contract,  its  characteristics, 
system  requirements,  and  development  events  leading  up  to  2008. 
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B.  MGS  ENGINEERING,  MANUFACTURING,  AND  DEVELOPMENT  (EMD) 
CONTRACT 

The  Army  selected  the  GDLS  MGS  model  primarily  because  of  its 
advantages  in  commonality  and  performance,  with  commonality  being  the 
“overriding  factor”  (Gamboa,  2001,  April  9,  p.  7).  However,  during  the  source- 
selection  process,  the  Source  Selection  Case  Authority  (SSA)  believed  that  the 
GDLS  MGS  model  presented  some  schedule  risk.  In  fact,  the  SSA  understood 
that  GDLS  “understated”  their  schedule  and  that  the  schedule  was  “inconsistent 
with  the  fundamental  terms  of  the  solicitation”  (Gamboa,  2001,  April  9,  p.  7). 

In  reference  to  the  RFP,  the  government  clearly  stated  that  the  program’s 
objectives  may  be  achieved  through  “the  acquisition  of  off-the-shelf,  non- 
developmental  items  with  integration  of  components,  traditional  development, 
[and]  systems  integration  [...]  staggered  over  time  and  across  variants” 
(Gamboa,  2001,  April  9,  p.  7).  However,  the  RFP  stipulated  that  the  Army 
understood  that  such  an  effort  should  stay  within  the  intent  of  fielding  a  system  in 
a  timely  manner. 

[The  Government]  does  not  anticipate  a  lengthy  development 
program  and  considers  extensive  development  of  solutions  to  be 
counter  to  the  thrust  of  this  acquisition  due  to  the  time,  cost  and  risk 
associated  with  such  an  approach.  (Gamboa,  2001,  April  9,  p.  7) 

The  Army  awarded  GDLS  with  a  cost-reimbursement  contract  for  EMD 
that  included  eight  preproduction  vehicles  for  Production  Qualification  Testing 
(PQT).  The  EMD  contract  used  performance-based  specifications,  and  it  did  not 
call  out  the  use  of  a  systems  engineering  process  in  the  statement  of  work 
(SOW)  (N.  Jenny  Chang,  Tank  &  Automotive  Command  Reliability  Engineer, 
personal  communication,  March  3,  2009).  At  this  point,  the  government  was 
unable  to  use  any  military  specifications  or  standards  unless  the  Milestone 
Decision  Authority  (MDA)  approved  a  waiver.  Additionally,  the  MGS  did  not 
contain  a  “design-in”  approach  for  reliability  as  a  requirement  in  the  contract,  and 
this  ensured  the  use  of  a  “test-in”  approach  during  EMD  (N.  Jenny  Chang,  Tank 
&  Automotive  Command  Reliability  Engineer,  personal  communication,  March  3, 
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2009).  The  EMD  contract  did  not  require  GDLS  to  conduct  any  contractor  testing 
prior  to  delivery  to  the  government  due  to  time  constraints  and  because  Program 
Executive  Office  Ground  Combat  System  (PEO  GCS)  believed  that  the  MGS  was 
close  to  ready  (Michael  Viggato,  Deputy  PEO  GCS,  personal  communication, 
December  12,  2008).  The  abbreviated  development  period  necessitated  the  use 
of  concurrent  contractor  and  government  testing  with  the  hope  that  the  vehicles 
would  fare  well  (Kim  McCormick,  GDLS  PM  MGS,  personal  communication, 
January  22,  2009). 

C.  MGS  CHARACTERISTICS  AND  REQUIREMENTS 

The  MGS  retained  the  same  common  armored  hull,  suspension,  power 
pack,  and  drivetrain  as  the  ICV  variant  of  the  Stryker.  Fully  combat  loaded 
(without  any  additional  armor),  the  MGS  weighs  approximately  47,500  pounds, 
and  a  three-man  crew  consisting  of  a  vehicle  commander,  gunner,  and  driver 
operate  the  vehicle  (GDLS,  2002,  p.  7)  (see  Figure  5). 
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Figure  5.  Mobile  Gun  System  Characteristics  (From  McCarroll,  2008, 

slide  37) 
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A  Caterpillar  3126A-HEUI  diesel  engine  that  uses  an  Allison  MD  3066 
automatic  transmission  powers  the  MGS,  and  it  has  the  option  of  operating  in 
either  the  8  x  4  or  the  8x8  mode.  The  MGS  integrates  a  Low  Profile  Turret  that 
houses  a  similar  105mm  main  gun,  the  M-68A2,  as  the  early  version  of  the  M-1 
tank.  The  secondary  armament  consists  of  a  coaxially  mounted  7.62mm 
machine  gun  and  a  commander’s  M-2  .50  caliber  machine  gun  (see  Figure  6). 


Figure  6.  Exterior  View  of  the  Stryker  Mobile  Gun  System  (From  GDLS, 

2002,  p.  8) 

The  remainder  of  this  section  describes  the  MGS  role  within  the  SBCT;  it 
also  describes  the  system  requirements  in  terms  of  firepower,  survivability,  and 
the  command,  control,  communications,  intelligence,  surveillance,  and 
reconnaissance  (C4ISR). 

1.  MGS  Requirements 

Prior  to  General  Shinseki’s  announcement  in  1999  of  his  vision  for  the 
Interim  Force,  the  Army’s  user  community  began  work  on  a  requirements 
document  for  a  medium-force.  The  user  community  used  the  insights  from  the 
PPD  to  refine  their  requirements,  and  it  completed  the  IAV  ORD  in  March  2000 
(PM  SBCT,  2008,  slide  6).  The  user  community  also  updated  the  Stryker  ORD 
as  part  of  the  Stryker  Milestone  B,  and  it  went  for  approval  by  the  Joint 
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Requirements  Oversight  Council  (JROC)  in  February  2004  (Andrews,  2004,  slide 
13).  The  JROC  has  a  significant  oversight  role  in  the  Joint  Capabilities 
Integration  and  Development  System  (JCIDS). 

The  JROC  encourages  collaboration  between  the  services,  ensures  that 
the  services  develop  capabilities  in  the  joint  warfighting  paradigm,  reviews  the 
requirements  of  programs  that  may  have  a  joint  interest  or  impact,  and  validates 
Key  Performance  Parameters  (KPPs)  (CJCS,  2007a,  May,  p.  2).  As  of  2008, 
the  Stryker  Capabilities  Development  Document  (CDD)  was  expected  to  receive 
JROC  approval  in  2009  (Fahey,  2008,  slide  42).  The  CDD  identifies  operational 
performance  attributes  of  the  proposed  system  or  increment  KPPs  and  it  is  a 
required  document  for  a  program’s  Milestone  B  review  (CJCS,  2007b,  May,  p.  B- 
1). 

Originally,  the  Stryker’s  user  proponent,  the  Training  and  Doctrine 
Command  (TRADOC)  System  Manager  (TSM),  was  located  at  Fort  Monroe, 
Virginia,  and  it  served  as  the  coordinating  organization  for  the  Stryker’s 
requirements.  In  2002,  the  Army  transferred  the  user  proponent  to  Fort  Benning, 
Georgia,  the  home  of  the  Army’s  Infantry  Center,  and  it  became  known  as  TSM 
SBCT.  In  2007,  the  Army  re-designated  TSM  SBCT  as  a  TRADOC  Capability 
Manager  (TCM)  and  it  was  renamed  TCM  SBCT.  Each  of  the  Army’s  branch 
proponents  provides  input  to  TCM  SBCT  on  the  Stryker’s  Mission  Equipment 
Packages  (MEPs).  The  Armor  Center,  located  at  Fort  Knox,  Kentucky,  provided 
input  for  the  MGS  MEP. 

2.  The  Role  of  the  MGS  within  the  SBCT 

The  MGS  provides  a  medium-infantry  support  capability  to  the  SBCT 
Combined  Arms  Company,  and  it  complements  the  nine  other  Stryker  variants. 
The  ORD  describes  the  critical  nature  of  the  MGS: 

The  MGS  is  essential  in  setting  and  maintaining  the  tactical 
conditions  for  this  collective  overmatch  by  providing  the  capability 
to  rapidly  and  in  succession  engage  and  destroy  a  diversity  of 
stationary  and  mobile  threat  personnel,  infrastructure,  and  materiel 
targets.  It  will  have  the  capability  to  apply  a  broad  spectrum  of 
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munitions  with  lethal  effects  under  all  weather  and  visibility 
conditions.  (Federation  of  American  Scientists,  2000) 

The  MGS  Annex  of  the  ORD  states  that  the  “principal  function  of  the  MGS  is  to 
provide  rapid  and  lethal  direct  fires  to  support  assaulting  infantry”  (Federation  of 
American  Scientists,  2000). 

3.  Firepower 

The  primary  requirement  of  the  MGS  is  to  provide  the  infantry  with 
supporting  fires  (also  a  KPP),  particularly  with  destroying  enemy  bunkers  and 
sniper  positions.  With  its  105mm  main  gun,  the  MGS  is  required  to  defeat  a 
threat  infantry  squad  at  a  minimum  distance  of  50  meters  and  at  a  maximum 
distance  of  500  meters.  The  MGS  also  has  to  deliver  this  lethal  fire  with 
precision  against  fighting  positions  in  buildings  and  light  structures.  Although  it 
was  required  to  destroy  a  variety  of  vehicles  ranging  from  light-skin  trucks  to  T-62 
tanks,  the  ORD  stipulated  this  be  for  self-defense  only.  The  main  gun  can 
depress  to  -5  degrees,  elevate  to  +15  degrees  over  the  front  of  the  vehicle,  and 
+9  degrees  over  the  rear  of  the  vehicle  (Federation  of  American  Scientists, 
2000).  The  turret  and  main  gun  is  powered  with  an  electric  drive  system  similar 
to  that  of  the  Bradley  Fighting  Vehicle  with  both  stabilized  and  non-stabilized 
modes  as  well  as  a  manual  back-up  (Federation  of  American  Scientists,  2000). 

The  MGS  has  an  M-240C  7.62mm  coaxially  mounted  machine  gun  on  the 
left  side  of  the  main  gun  that  can  accurately  engage  threat  troops  at  a  maximum 
effective  range  of  900  meters.  The  M-240C  elevates  and  depresses  with  the 
main  gun  and,  therefore,  has  the  same  elevation  and  depression  requirements 
as  the  main  gun.  Both  the  commander  and  gunner  control  the  main  gun  and 
coaxially  mounted  machine  gun.  The  MGS  also  stores  18  main  gun  rounds  with 
all  18  in  a  ready  configuration  (Gary  Gerlach,  Project  Engineer,  PEO  GCS, 
personal  communication,  January  20,  2009). 

The  fire  control  system  supporting  the  main  gun  and  coaxial  machine  gun 
provides  day  and  night  engagement  capability  in  all  types  of  weather.  The 
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Compact  Modular  Sight  (CMS)  provides  a  forward-looking  infrared  sight  (FUR), 
eye-safe  laser  range  finder  (ELRF),  and  direct  view  optics  (Gary  Gerlach,  Project 
Engineer,  PEO  GCS,  personal  communication,  January  20,  2009). 

4.  Survivability 

The  crew  of  the  MGS  has  the  same  level  of  protection  and  survivability  as 
the  ICV  variants.  The  base  armor  of  the  Stryker  is  required  to  provide  360- 
degree  protection  against  7.62mm  fire  and  14.5mm  protection  with  additional 
armor  protection. 

The  initial  requirements  for  the  MGS  did  not  stipulate  the  use  of  armor 
protection  for  the  main  gun  or  coaxial  machine,  although  it  did  require  full 
protection  for  the  crew  inside  of  the  turret.  To  protect  the  three-man  crew  from  a 
secondary  explosion  of  the  main  gun’s  ammunition,  the  MGS  stores  the  main 
gun  ammunition  separately  from  the  crew  (TRADOC,  2008,  p.  19). 

5.  C4ISR 

The  C4ISR  requirements  on  the  MGS  are  similar  to  those  on  the  ICV 
variants.  As  part  of  the  SBCT,  the  MGS  can  rapidly  share,  understand,  and 
network  information  to  achieve  a  common  operating  picture  (TRADOC,  2008,  p. 
6).  The  networking  capability  of  the  Stryker  allows  the  SBCT  to  span  a  larger 
area  than  Legacy  formations  and  to  respond  in  a  rapid  manner  to  changes  in  the 
operating  environment. 

The  networking  capability  is  particularly  important  to  the  MGS.  The  ability 
of  the  MGS  to  receive  information  from  other  Stryker  platforms  and  infantrymen 
allows  it  to  provide  long-range,  precision  firepower.  The  MGS  also  has  the  same 
level  of  interoperability  with  current  C4ISR  suites  as  the  ICV  variants.  The 
C4ISR  system  consists  of  the  following: 

•  Intercom  System, 

•  Radio  System, 

•  Force  XXI  Battle  Command,  Brigade  and  Below  (FBCB2)  System, 
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•  Ethernet  Hub, 

•  Ground  Positioning  System, 

•  Driver’s  Vision  Enhancer  (DVE), 

•  Training  Aids  Devices  Simulators  and  Simulations  (TADSS),  and 

•  Embedded  Training  Computer  (ETC).  (GDLS,  2002,  p.  14) 

The  radio  system  consists  of  two  Single  Channel  Ground  Air  Radio 
Systems  (SINCGARS)  radios  (long  range  and  short  range)  and  an  EPLRS  radio. 
The  FBCB2  system  communicates  through  the  EPLRS  and  the  GPS  provides 
the  FBCB2  with  positional  data  (GDLS,  2002,  p.  14). 

D.  MGS  DEVELOPMENT 

As  of  June  2009,  the  MGS  was  nearing  the  end  of  its  developmental 
period.  For  the  purpose  of  this  case  study,  one  can  view  its  development  in  four 
overlapping  stages.  Chronologically,  these  stages  are  selection,  protest  and 
prototype  development  (2000-2002),  early  testing  (2003),  reliability  growth 
(2004-2006),  and  deployment  and  the  path  to  full-rate  production  (Fall  2006- 
2009).  The  focus  of  the  case  study  is  on  the  reliability  growth  period  from  2004- 
2006;  however,  a  clear  understanding  of  the  events  leading  up  to  this  period  is 
essential. 

The  early  stages  of  the  MGS  followed  a  turbulent  cycle  of  development 
until  the  MGS  PMO  instituted  the  use  of  systems  engineering  methodology  to 
integrate  all  of  the  program’s  activities.  Prior  to  the  implementation  of  the 
systems  engineering  approach,  the  program  experienced  a  turbulent 
development  period.  The  Army  deployed  the  MGS  to  Operation  Iraqi  Freedom  in 
2007  where  it  received  positive  feedback  from  soldiers  (Censer,  2008,  April  15). 

1.  Stage  1-Selection,  Protest,  and  Prototype  Development  (2000- 
2002) 

During  the  November  2000  Stryker  Defense  Acquisition  Board  (DAB) 
meeting,  the  Defense  Acquisition  Executive  (DAE)  required  successful 
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completion  of  six  exit  criteria  for  the  MGS  prior  to  its  entrance  into  Low-rate  Initial 
Production  (LRIP)  (PM  SBCT,  2008,  slide  34)  (see  Figure  7). 


MGS  Engineering  &  Manufacturing  Development 
(EMD)  Phase  Exit  Criteria 

IAV  Acquisiton  Decision  Memorandum  (16  NOV  00)1 

Performance  Measure 

Criteria 

Interoperability 

Demonstrate  Successful  Integration  of  FBCB2 

Mobility 

Demonstrate  sustained  hard  surface  road  speeds 

of  40  mph 

System  Reliability  (Less  GFE) 

Demonstrate  position  on  a  reliability  growth  curve 
to  meet  an  80%  confidence  of  achieving  1000 

MMBCF 

Support  ability 

Demonstrate  the  ability  to  self- recover 

Mission  Equipment  Package 
(Lethality) 

Demonstrate  successful  operation  of  an  integrated 
cannon  system  to  defeat  reinforced  concrete  wall 
with  5  rounds 

Average  Unit  Procurement  Cost 
(AUPC)-MGS 

AUPC  less  than  or  equal  to  Objective  - 
$4  7M(TY)/$4  2M(BY) 

Threshold  -$5  4M(TY;/$4  8M(BY) 

Figure  7.  EMD  Exit  Criteria  (From  PM  SBCT,  2008,  slide  34) 


Soon  after  the  start  of  work  for  the  contract  in  April  2001,  GDLS  initiated 
the  production  of  the  eight  preproduction  MGS  models.  In  July  2002,  the  MGS 
PMO  believed  that  the  program  required  27  months  of  development  prior  to  Low- 
rate  Initial  Production  (LRIP)  in  June  2003  (Hsu,  2002,  July  22).  The  initial  LRIP 
was  2002,  but  the  program  manager  moved  it  to  2003  based  on  the  award 
protest. 

The  development  of  the  eight  preproduction  models  took  place  at  the 

General  Dynamics  Muskegon  Technology  Center  in  Michigan.  The  Muskegon 

Technology  Center  provided  GDLS  with  the  capabilities  needed  to  handcraft 

eight  vehicles  for  Production  Qualification  Testing  (PQT).  In  March  1996,  GDLS 

purchased  the  Muskegon  Technology  Center  from  the  Teledyne-Waterpik 
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Corporation;  the  facility  specialized  in  the  development  of  handcrafted  armored 
vehicle  prototypes  (LTC  Shane  Fullmer,  personal  communication,  February  27, 
2009).  Additionally,  Teledyne-Waterpik’s  Muskegon  technology  facility  was  the 
original  designer  of  the  Low  Profile  Turret  (LPT)  for  the  LAV  III,  and  it  had  the 
engineering  expertise  to  develop  these  vehicles  for  the  Army  (LTC  Erik  Webb, 
personal  communication,  December  5,  2008). 

However,  the  processes  of  the  Muskegon  facility  concentrated  on 
handcrafted  research  and  development  activities,  not  on  production  (Kim 
McCormick,  GDLS  PM  MGS,  personal  communication,  January  22,  2009).  The 
engineers  at  Muskegon  had  previously  worked  with  the  Aries  auto-loader  portion 
of  the  ammunition  handling  system,  and,  as  a  result,  they  were  confident  that 
they  could  successfully  integrate  the  replenisher  as  well.  The  mindset  of  the 
engineers  at  Muskegon  was  that  they  could  accomplish  anything  given  enough 
time  (LTC  Shane  Fullmer,  personal  communication,  February  27,  2009). 

In  July  2002,  the  Army  received  its  first  pre-production  model,  but  PQT 
would  not  begin  until  November  2002.  The  MGS  prototypes  differed  from  the 
demonstration  version  used  during  the  2000  PPD  in  that  they  had: 

•  Increased  armor  protection, 

•  An  integrated  C4ISR  suite, 

•  An  integrated  ten-round  replenisher, 

•  A  7.62mm  coaxial  machine  gun, 

•  A  .50  caliber  commander’s  machine  gun, 

•  A  commander’s  panoramic  viewer  integrated  with  the  fire  control 
system, 

•  An  eight-round  carousel  as  opposed  to  a  nine-round  version,  and 

•  Fire  control  modification  to  integrate  all  main  gun  ammunition  and 
coaxial  machine  guns.  (Gourley,  2003,  May) 

The  initial  preproduction  vehicles  received  in  July  2002  did  not  contain  the 

entire  AHS.  These  vehicles  had  the  auto-loader  system  but  lacked  the 

replenisher,  which  GDLS  did  not  deliver  until  September.  Even  then,  it  took  over 
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a  month  to  get  the  replenisher  to  line  up  a  round  to  feed  into  the  auto-loader 
system’s  carousel  located  in  the  Low  Profile  Turret  (LTC  Shane  Fullmer, 
personal  communication,  February  27,  2009).  Several  individuals  in  the  MGS 
PMO  immediately  realized  that  the  Aries  AHS  design  would  present  problems, 
but  the  extent  of  these  problems  was  uncertain  until  the  test  community  verified 
them  during  PQT  (LTC  Shane  Fullmer,  personal  communication,  February  27, 
2009).  The  PM  planned  for  the  PQT  to  support  a  scheduled  Low-rate  Initial 
Production  (LRIP)  decision  in  June  2003.  In  late  2001,  the  Army  planned  to  field 
the  MGS  to  the  first  SBCT  in  2005  (see  Figure  8). 

The  first  set  of  challenges  that  the  MGS  PMO  anticipated  was  the 
vehicle’s  weight.  To  meet  the  C-130  Transportability  KPP,  the  MGS’s  PQT 
weight  limit  was  40,592  pounds,  and  the  initial  prototypes  were  approximately 
43,865  pounds.  Although  the  MGS  was  overweight  by  5,000  pounds,  the  Army 
continued  with  the  June  2003  LRIP  decision  because  it  had  a  two-stage  weight 
reduction  program  in  place  to  ensure  the  MGS  met  the  C-130  KPP  (Winograd, 
2002,  November  25). 
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Figure  8.  MGS  Program  Schedule  Adjustments  April  2001-January  2002 

(From  PM  SBCT,  2008,  slide  45) 


2.  Stage  2-Early  Testing  (2003) 

The  Army  began  its  PQT  at  Aberdeen  Proving  Ground  in  February  2003. 
Soon  after  PQT  began,  the  Army  was  disappointed  with  the  mounting  problems 
found  in  the  MGS  prototypes.  The  intent  of  the  PQT  was  to  provide  system-level 
testing  to  determine  the  stability  of  the  design  and  its  readiness  for  production. 
This  meant  that  the  failure  modes  should  have  been  known  and  consistent; 
however,  new  failure  modes  were  frequently  appearing  (LTC  Erik  Webb, 
personal  communication,  March  10,  2009).  This  indicated  that  the  design  was 
unstable  and  that  it  needed  sub-component  testing.  First,  the  MGS  showed  50 
problems  with  human  systems  integration,  known  as  Manpower  and  Personnel 
Integration  (MANPRINT),  and  it  had  to  reconfigure  much  of  the  C4ISR 
components  to  allow  soldiers  to  fit  and  function  inside  the  vehicle.  Second,  the 
Army  noticed  a  problem  with  the  ammunition  handling  system  (AHS).  The  AHS 
had  difficulty  reloading  ammunition  because  of  the  alignment  between  the 
replenisher  and  the  carousel  (Baumgardner,  2003,  May  23).  Third,  after  lowering 
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the  105mm  turret  five  inches  to  meet  the  C-130  Transportability  KPP,  the  blast 
overpressure  from  the  main  gun  muzzle  brake  was  causing  a  halo  effect  on  the 
front  of  the  vehicle,  damaging  components  mounted  to  the  external  hull  (Joseph 
Godell,  Deputy  PM  MGS,  personal  communication,  March  6,  2009). 

The  engineering  effort  involved  in  lowering  the  turret  caused  the  Army  to 
suspend  PQT  for  two  months  (Joseph  Godell,  Deputy  PM  MGS,  personal 
communication,  January  6,  2009).  GDLS  determined  that  the  recoil  mechanism 
could  absorb  the  additional  recoil  without  any  redesign,  beyond  the  elimination  of 
the  muzzle  brake  (Joseph  Godell,  Deputy  PM  MGS,  personal  communication, 
January  8,  2009).  The  PQT  began  again  in  July  2003  and  the  Army  completed  it 
in  November  2003.  These  engineering  issues  led  to  the  rescheduling  of  LRIP  to 
February  2004  and  then  to  September  2004. 

Despite  the  problems  encountered  during  PQT,  the  Army  was  satisfied 
with  the  GDLS  fixes  to  the  MANPRINT  problems,  main  gun  overpressure  and 
recoil,  and  the  AHS.  The  Army  then  proceeded  to  the  LRIP  decision  in 
September  2004.  To  meet  the  criteria  for  LRIP,  the  MGS  had  to  meet  all  of  its 
Key  Performance  Parameters  (KPPs)  to  include  the  C-130  KPP,  the  vehicle  cost 
objective,  and  a  requirement  to  achieve  1,000  mean  miles  between  system  abort 
(half  of  the  requirement  of  the  ICV)  (Roosevelt,  2004,  August  11).  The  Army 
defined  system  abort  as  any  type  of  significant  system  failure  that  occurred  on 
the  vehicle.  Of  the  six  exit  criteria,  the  system  abort  requirement  was  the  most 
ambiguous  because  it  did  not  clearly  define  the  minimal  reliability  requirement  for 
the  auto-loader  system. 

The  Defense  Acquisition  Executive  (DAE),  Michael  Wynne,  chaired  the 
Defense  Acquisition  Board  (DAB)  meeting  that  determined  the  LRIP  decision. 
The  DAB  made  a  determination  based  on  the  analysis  of  the  test  results  from  the 
Director  of  Operational  Testing  &  Evaluation  (DOT&E)  and  the  Army  Test  and 
Evaluation  Command  (ATEC).  The  analysis  stated  that  the  MGS  met  the 
requirements  for  operational  effectiveness,  but  fell  short  of  meeting  the  minimum 
criteria  for  operational  suitability,  mainly  because  of  the  MEP  reliability  (Wynne, 
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2004,  p.  1).  At  the  DAB  meeting,  Wynne  expressed  substantial  concern  over  the 
reliability  of  the  MGS,  but  he  still  approved  the  limited  LRIP  of  14  vehicles  with 
several  caveats.  His  doubts  centered  on  the  ammunition  handling  system,  and 
he  required  the  Army  to  update  the  Stryker  Systems  Engineering  Plan  (SEP) 
within  90  days  (Joseph  Godell,  Deputy  PM  MGS,  personal  communication, 
January  6,  2009).  It  was  at  this  point  that  the  Army  began  to  adjust  its 
expectations  for  the  MGS.  Rewriting  the  SEP  would  entail  a  complete  review  of 
the  design  and  the  approach  towards  improving  reliability. 

After  the  September  2004  DAB  meeting,  the  MGS  PMO  became  acutely 
aware  that  the  development  of  the  MGS  would  require  even  more  time  than  was 
expected  as  well  as  additional  patience  (DiMascio,  2004,  October  11).  As  the 
schedule  of  the  MGS  continued  to  slip,  elements  of  the  user  community 
compounded  the  technical  problems  caused  by  the  auto-loader’s  reliability  when 
they  changed  the  requirements  for  the  armor  protection  of  the  MGS  (DiMascio, 
2004,  October  11). 

3.  Stage  3-Reliability  Growth  (2004-2005) 

While  the  ICV  chassis  that  the  MGS  used  was  highly  reliable,  the  low 
inherent  reliability  of  the  Mission  Equipment  Package  (MEP)  reduced  the  overall 
reliability  of  the  MGS.  Failure  data  collected  during  PQT  pointed  towards  the 
three  components  that  made  up  the  AHS  as  the  major  cause  for  poor  MEP 
reliability  and,  in  particular,  the  AHS  replenisher  (Joseph  Godell,  Deputy  PM 
MGS,  personal  communication,  January  6,  2009). 

The  difference  between  the  actual  reliability  of  less  than  20  rounds  per 
Operational  Mission  Scenario/Mission  Profile  (OMS/MP)  cycle  and  the  required 
reliability  of  at  least  90  rounds  per  mission  cycle  without  a  failure  was 
significant,  and  this  required  tremendous  persistence  and  innovation  to  remedy 
(LTC  Erik  Webb,  personal  communication,  May  20,  2009).  Both  the  Army  and 
GDLS  knew  that  drastic  measures  were  necessary  to  increase  the  overall 
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reliability  of  the  MEP,  and  this  required  a  costly  and  extensive  reengineering 
effort  that  led  to  a  change  in  the  schedule  (see  Figure  9). 


Figure  9.  Stryker  MGS  Program  Comparison  Schedule  (April  2001  and 
August  2005)  (From  PM  SBCT,  2008,  slide  49) 


The  problems  with  the  auto-loader  caused  GDLS  to  abandon  its  original 
auto-loader  design,  developed  by  Aries,  and  instead  use  a  contractor-initiated 
source  selection  to  choose  a  new  sub-contractor,  Western  Design,  which 
proposed  a  more  reliable  design  (Joseph  Godell,  Deputy  PM  MGS,  personal 
communication,  January  6,  2009).  The  MGS  PMO  employed  a  Reliability  Growth 
Analysis  (RGA)  methodology  based  on  systems  engineering  to  provide  the 
program  leadership  with  the  information  needed  to  make  decisions  on  resourcing 
and  scheduling  (Chang,  N.J.  &  Rohall,  D.J.,  2008,  September,  p.  267).  The 
MGS  PMO  encountered  the  problem  of  testing  for  numerical  reliability  targets 
midway  through  development,  when  reliable  systems  are  often  the  result  of  the 
early  use  of  systems  engineering  fundamentals  (Defense  Science  Board,  2008, 
May,  p.  5).  The  use  of  systems  engineering  uncovers  problems  at  an  early  stage 
when  the  program  can  incrementally  correct  them.  The  case  study  explores  this 
topic  in  a  more  detail  within  Chapter  V. 
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While  the  reliability  issues  were  occurring,  the  Army’s  user  community  and 
the  Director  of  Operational  Testing  and  Evaluation  (DOT&E),  under  the  Office  of 
the  Secretary  of  Defense  (OSD),  made  the  determination  that  the  MGS  PMO 
needed  to  increase  the  gun  pod’s  armor  protection  based  on  modeling  and 
simulation  of  future  tactical  scenarios.  The  additional  capabilities  requested  by 
the  user  community  and  the  OSD  required  additions  to  the  updated  MGS  TEMP 
as  well  as  further  reengineering  effort.  The  increase  in  armor  protection  required 
trade-offs  in  capabilities  to  ensure  that  the  MGS  met  the  C-130  KPP.  The  MGS 
PMO  now  faced  the  issue  of  improving  the  MGS  reliability  and  gun  pod 
survivability  while  concurrently  maintaining  an  acceptable  system  weight 
(DiMascio,  2005,  January  24). 

The  new  auto-loader  contractor,  Western  Design,  replaced  the  replenisher 
to  reduce  the  complexity  of  the  auto-loading  and  replenishing  mechanisms.  The 
Aries  replenisher  had  consisted  of  two  five-round  drums,  whereas  the  Western 
Design  replenisher  consisted  of  one  ten-round  drum.  After  several  months  of 
intensive  RGA  effort  as  part  of  the  test  program,  the  reliability  of  the  system  was 
approaching  the  necessary  parameters.  Consequently,  the  new  DAE,  Ken  Krieg, 
approved  the  final  LRIP  of  58  vehicles  in  October  2005  after  reviewing  the  new 
operational  suitability  test  results  (DiMascio,  2005,  November  14).  Although 
reliability  growth  was  not  the  final  development  hurdle  for  the  MGS,  it  opened  the 
way  for  the  LRIP  decision. 

The  use  of  the  RGA  and  systems  engineering  process  provided  the  MGS 
Program  Office  with  an  objective  means  of  understanding  what  was  occurring 
with  the  MGS  during  testing.  By  2006,  the  MGS  was  exceeding  its  reliability 
targets. 

4.  Stage  4-Deployment  and  the  Path  to  Full-rate  Production 
(2006-2008) 

After  production  approval  for  the  remaining  58  LRIP  vehicles,  the  MGS 
Program  conducted  additional  Production  Verification  Testing  (PVT),  beginning  in 
February  2006.  The  purpose  of  the  PVT  was  to  provide  information  to  support 

62 


the  Milestone  III  decision  for  Full-rate  Production  (FRP),  scheduled  for  2007 
(DiMascio,  2005,  December  12).  To  meet  the  Milestone  III  requirements,  the 
MGS  also  had  to  undergo  Live  Fire  Test  and  Evaluation  (LFT&E)  and  an  Initial 
Operational  Test  (IOT). 

Although  the  Army  had  a  Full  Rate  Production  decision  scheduled  for 

2007,  the  Iraq  Surge  diverted  the  Fort  Lewis-based  test  unit,  the  4th  Stryker 
Brigade  Combat  Team  of  the  2nd  Infantry  Division,  a  unit  that  the  Army  had 
previously  scheduled  to  support  the  MGS  IOT.  The  Army  subsequently 
rescheduled  the  Full  Rate  Production  decision  for  February  2008  after  it 
designated  another  SBCT  as  the  IOT  support  unit  (Joseph  Godell,  Deputy  PM 
MGS,  personal  communication,  January  6,  2009). 

While  the  MGS  still  required  LFT&E  and  operational  testing,  the  Chief  of 
Staff  of  the  Army,  General  Peter  Schoomaker,  determined  that  the  MGS  was 
capable  of  operational  deployment  with  the  4th  SBCT/2nd  ID  to  Iraq.  He  based 
this  decision  on  the  recommendation  from  the  December  2006  Army  System 
Acquisition  Review  Council  (ASARC)  (Joseph  Godell,  Deputy  PM  MGS,  personal 
communication,  January  8,  2009).  Although  the  Army  acknowledged  that  the 
MGS  required  “fixes”  during  its  deployment,  the  vehicle  successfully  performed 
its  mission  in  theater  (Joseph  Godell,  Deputy  PM  MGS,  personal  communication, 
January  8,  2009). 

To  resolve  these  concerns,  the  MGS  PMO  and  GDLS  implemented 
accuracy  improvements  to  the  coaxial  machine  gun,  reliability  fixes  to  the 
electronic  power  components,  a  better  cooling  system  for  the  vehicle’s  three-man 
crew,  and  software  improvements  to  the  commander’s  display  unit  (Censer, 

2008,  May  19).  To  address  these  issues,  the  MGS  PMO  developed  a  near-,  mid- 
and  far-term  plan  to  implement  the  fixes  recommended  by  the  DOT&E  to  allow 
FRP  of  the  MGS.  The  Army  then  conducted  a  Configuration  Steering  Board 
(CSB)  in  October  2008  to  review  the  product  manager’s  mitigation  plan  and  the 
impacts  of  implementing  the  changes  on  cost  and  schedule  (Roosevelt,  2008, 
August  22,  p.  1).  The  recommended  fixes  included  both  requirements  shortfalls 
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from  the  base  MGS  requirement  document,  observations  from  the  use  of  the 
MGS  in  theater,  and  DOT&E  observations  from  testing  that  were  not  traceable  to 
an  approved  requirements  document  (COL  Robert  Schumitz,  PM  SBCT, 
personal  communication,  January  29,  2009). 

E.  CONCLUSION 

While  the  MGS  program  offers  a  useful  case  study  for  lessons  learned, 
the  developmental  challenges  encountered  were  not  idiosyncratic  to  this 
program.  The  Army  has  encountered  similar  problems  with  complexity  in  other 
acquisition  programs.  In  fact,  a  GAO  report  on  the  SGT  York,  an  air  defense 
weapon  system  developed  in  the  early  1980s,  revealed  this: 

One  reason  for  the  delay  in  fielding  the  (system)  was  that  the 
prototype  gun  systems  the  contractors  delivered  for  testing  were 
less  technically  mature  than  anticipated.  This  caused  testing 
delays  and  the  need  for  more  testing  than  had  been  planned.  The 
integration  of  the  weapon’s  major  subsystems  and  their  application 
to  a  weapon  for  which  they  had  not  been  originally  designed 
apparently  represented  a  greater  technical  undertaking  than 
originally  anticipated.  (Conahan,  1986,  pp.  4-5) 

Outside  of  the  MGS  program,  there  was  tremendous  support  for  the  MGS. 
General  Peter  Schoomaker,  the  Army’s  Chief  of  Staff  after  General  Shinseki,  was 
a  “stalwart  supporter”  of  the  MGS  (DiMascio,  2005,  January  24).  This  chapter 
provided  a  broad  overview  of  what  capability  the  Army  needed  from  the  MGS  as 
well  as  a  chronological  progression  of  how  it  evolved  from  2000  to  2008. 

The  focus  of  Chapter  V  is  on  the  MGS  development  from  2000-2005,  with 
an  emphasis  on  how  the  MGS  program  adapted  to  the  complexity  of  the  outer 
environment  by  analyzing  the  system’s  integration  of  the  ammunition  handling 
system. 
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V.  MANAGING  COMPLEXITY 


A.  INTRODUCTION 

A  program’s  developmental  trajectory  is  seldom  smooth,  and  it  typically 
involves  overcoming  unanticipated  challenges.  Chapter  IV  provided  a  brief 
description  of  some  of  the  developmental  challenges  that  the  MGS  encountered. 
In  many  ways,  everything  was  harder  than  expected  for  the  MGS,  particularly 
with  systems  integration  (COL  Robert  Schumitz,  PM  SBCT,  personal 
communication,  November  25,  2008).  The  initial  momentum  of  the  program  and 
the  commitment  to  success  by  the  program’s  leadership  overcame  some  of  these 
challenges,  but  the  MGS  required  a  change  in  approach  to  make  it  through  the 
crisis  period  of  2004-2005.  The  crisis  occurred  because  of  an  inability  to  meet 
reliability  objectives  for  LRIP,  but  the  root  cause  of  the  crisis  was  an  approach 
that  did  not  adequately  address  the  complex  environment.  To  meet  the  demands 
of  the  complex  environment,  the  MGS  PMO  self-organized  around  a  systems 
approach  that  identified  and  managed  risk. 

The  primary  area  of  risk  for  the  program  during  this  period  was  the  low 
level  of  reliability  for  the  MGS  ammunition  handling  system  (AHS).  This  chapter 
provides  an  overview  of  the  AHS,  the  problems  experienced  with  the  AHS,  the 
systems  engineering  approach  adopted  by  the  MGS  PMO  and  GDLS,  and  then 
closes  with  an  analysis  of  the  program’s  adaptation  to  the  complex  environment. 

B.  THE  AMMUNITION  HANDLING  SYSTEM 

1.  Aries  Design 

Early  on,  GDLS  sub-contracted  with  the  Aries  Company  for  a  previously 
developed  AHS  under  a  fixed-price  contract  (LTC  Shane  Fullmer,  personal 
communication,  February  27,  2009).  Aries  had  an  off-the-shelf  auto-loader 
available,  but  it  required  the  development  of  a  replenisher  system  for  the  MGS. 
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For  the  MGS,  the  AHS  consisted  of  three  components:  1)  a  carousel,  2)  a 
rammer,  and  3)  a  replenisher  (see  Figure  10). 
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Figure  10.  The  Ammunition  Handling  System  (From  GDLS,  2005c,  slide  3) 

The  Aries  design  used  pneumatic  power,  and  it  had  eight  rounds  in  the 
carousel  with  ten  rounds  in  two  separate  5-round  drums.  When  commanded  to 
load  a  round,  the  eight-round  carousel  raised  the  12  o'clock  position  tube 
containing  the  desired  round  and  the  hydraulically  actuated  rammer  picked  up 
the  round  from  the  carousel,  and  transferred  it  to  the  gun  breach,  where  it 
was  loaded  (LTC  Erik  Webb,  personal  communication,  May  20,  2009).  To  reload 
the  carousel,  rounds  were  pneumatically  loaded  into  the  carousel  located  in  the 
Low  Profile  Turret  (GDLS,  2005b,  slide  3).  There  were  early  indications  that  the 
AHS  was  problematic.  Soon  after  the  delivery  of  the  first  pre-production  vehicles 
in  2002,  the  Army  noticed  that  the  Aries  AHS  had  difficulty  with  aligning  rounds 
while  transferring  them  from  the  replenisher  to  the  auto-loader. 
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2.  Reliability  in  Early  PQT  (2003) 


The  requirement  for  reliability  at  the  start  of  the  program  was  1,000  Mean 
Miles  Between  System  Abort  (MMBSA)  (Chang  et  al.,  2009,  March,  p.  3).  The 
MMBSA  measure  was  based  on  the  performance  specifications  within  the  RFP, 
which  required  the  developer  to  state  reliability  in  terms  of  “system  abort  failures” 
(Gamboa,  2001,  April  9,  p.  17).  Furthermore,  the  RFP  required  offerors  to 
“identify  predicted  or  demonstrated  system  level  reliability  for  each  IAV  variant  or 
configuration  and  to  discuss  failure  definition,  data  sources,  and  operating 
environment  profile  showing  applicability  to  the  lAVs”  (Gamboa,  2001,  April  9,  p. 
17).  As  part  of  the  proposal  package,  the  government  required  each  of  the 
offerors,  GDLS  in  this  case,  to  assess  its  own  predicted  reliability  in  view  of  the 
risks  associated  with  integrating  highly  complex  components.  Considering  the 
performance  of  the  AHS  during  PQT,  it  appears  that  GDLS  overestimated  the 
reliability  of  the  AHS. 

In  2003,  the  Army  conducted  Reliability,  Availability,  and  Maintainability 
(RAM)  testing  as  part  of  PQT  at  the  Aberdeen  Proving  Grounds.  During  this 
testing,  the  Army  required  the  vehicles  to  drive  8,000  miles  and  fire  640  rounds 
with  the  goal  of  achieving  an  80%  confidence  level  that  the  production  system 
could  achieve  1,000  MMBSA  (Baumgardner,  2003,  July  10,  p.  1).  The  AHS 
failed  to  achieve  the  required  system-level  reliability,  and  the  Army  terminated 
PQT  approximately  two-thirds  of  the  way  through  the  test  (Chang  et  al.,  2008, 
September,  p.  269). 

The  MGS  PMO  relied  on  a  “test-in”  approach  for  reliability  because  there 
was  not  a  Design  for  Reliability  (DFR)  requirement  in  the  original  contract,  and 
the  compressed  timeline  made  it  nearly  impossible  for  GDLS  to  conduct  DFR 
during  EMD  (N.  Jenny  Chang  Tank  &  Automotive  Command  Reliability  Engineer, 
personal  communication,  March  4,  2009).  During  PQT,  the  MGS  PMO  used  a 
closed-loop  Failure  Reporting  and  Corrective  Action  System  (FRACAS)  that  did 
not  provide  an  efficient  means  for  reliability  growth  because  of  a  slow  reaction 
time  in  identifying  where  failures  were  occurring  in  the  system.  One  of  the 
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consequences  of  the  slow  reaction  time  was  that  reliability  at  the  end  of  the  PQT 
was  essentially  the  same  as  the  reliability  at  the  beginning  (N.  Jenny  Chang  Tank 
&  Automotive  Command  Reliability  Engineer,  personal  communication,  March  4, 
2009). 

Based  on  these  results,  a  September  2004  Defense  Acquisition  Board 
(DAB)  review  required  the  MGS  PMO  to  improve  the  reliability  of  the  system  prior 
to  moving  to  LRIP.  Under  the  post-DAB  testing  plan,  the  DAE  required  that  the 
MGS  undergo  further  RAM  tests  in  FY04  and  1Q/FY05.  These  RAM  tests 
included  driving  12,000  miles  and  firing  1,000  rounds,  with  the  objective  of 
achieving  the  1,000  MMBSA  (DiMascio,  2004,  September  13).  One  outcome  of 
the  September  2004  DAB  was  that  the  MGS  PMO  and  GDLS  separated  the 
reliability  criterion  for  the  MGS  MEP  from  that  of  the  chassis.  The  measurement 
criterion  for  reliability  originates  from  two  contractual  documents  created  by  the 
user,  the  Operational  Mode  Summary  and  Mission  Profile  (OMS/MP)  and  the 
Failure  Definition  and  Scoring  Criteria  (FD/SC)  (Chang  et  al.,  2009,  March,  p. 
154). 

The  OMS/MP  is  an  appendix  to  the  system  requirements  documentation, 
and  the  purpose  of  the  OMS/MP  is  to  support  the  development  of  specifications 
and  test  plans  by  describing  how  a  system  will  operate  in  different  types  of 
scenarios  (DAU,  2009a).  The  FD/SC  is  a  jointly  developed  document  between 
the  user  and  the  materiel  developer  that  defines  system  failure  definitions  during 
reliability  testing  (DAU,  2009b).  Within  the  Stryker  OMS/MP,  the  MGS  performed 
two  functions:  accumulating  miles  and  firing  ammunition.  However,  the  reliability 
criteria  was  changed  because  the  MGS  chassis  was  the  same  as  the  ICV 
variant,  which  already  passed  its  reliability  tests,  and  the  cause  of  the  MGS 
reliability  shortfalls  centered  on  the  AHS  (Chang  et  al.,  2009,  March,  154). 

The  result  of  this  change  was  that  MGS  PMO  kept  the  requirement  for  the 
MMBSA  remained  at  1,000  miles,  and  they  re-designated  the  new  MEP  reliability 
as  Mean  Rounds  Between  System  Abort  (MRBSA),  with  a  threshold  performance 
of  81  MRBSA  and  an  objective  performance  of  148  MRBSA  (Chang  et  al.,  2009, 
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March,  p.  154).  Soon  thereafter,  the  MGS  PMO  directed  GDLS  to  abandon  the 
Aries  design  and  to  find  a  new  design  for  the  AHS  as  well  as  a  new  approach  to 
improving  the  system  reliability. 

C.  RELIABILITY  AS  A  DESIGN  CONSIDERATION  DURING  THE 
SYSTEMS  ENGINEERING  PROCESS 

As  a  requirement,  system  reliability  is  an  important  design  consideration 
throughout  the  systems  engineering  process,  and  it  plays  a  critical  role  in  a 
systems  lifecycle.  According  to  Blanchard  and  Fabrycky, 

Every  system  is  developed  in  response  to  a  customer  need  to  fulfill 
some  anticipated  function.  The  effectiveness  with  which  the 
system  fulfills  this  function  is  the  ultimate  measure  of  its  utility  and 
value  to  the  customer  [...].  [S]ystem  effectiveness  is  a  composite  of 
many  factors  with  reliability  being  a  major  contributor.  (2006,  p. 

285) 

After  conducting  a  functional  analysis,  the  developer  constructs  a  reliability  block 
diagram  that  allocates  reliability  from  a  top-down  approach.  The  allocation  of 
reliability  also  serves  as  an  input  for  Failure  Mode  Effect  and  Criticality  Analysis 
(FMECA)  (Blanchard  &  Fabrycky,  2006,  p.  385).  Through  the  application  of  a 
systems  engineering  approach,  the  materiel  developer  designs  for  reliability 
(DFR),  as  opposed  to  testing  for  reliability  (TFR)  as  an  afterthought.  Although 
the  DFR  approach  requires  sophisticated  methodology,  it  is  more  cost-effective 
than  the  TFR  approach.  As  a  critical  element  of  a  system’s  overall  performance, 
the  developer  addresses  reliability  in  all  stages  of  the  systems  engineering 
lifecycle  model  (see  Figure  1 1 ). 
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Figure  11.  Systems  Engineering  Lifecycle  Model  with  Reliability 
Embedded  (From  Blanchard  &  Fabrycky,  2006,  p.  383) 


According  to  the  Army  Materiel  Systems  Analysis  Activity  (AMSAA) 
Reliability  Growth  Guide,  the  consideration  of  reliability  “is  part  of  the  systems 
engineering  process,”  and  systems  engineering  is  merely  a  means  of  “viewing 
reliability  program  activities  in  an  integrated  manner”  (2000,  September,  p.  4). 
The  different  reliability  activities  include  design  predictions,  apportionment,  failure 
modes  and  effects  analysis,  and  stress  analysis  (AMSAA,  2000,  September,  p. 
4). 

In  short,  reliability  growth  is  a  proven  method  to  reduce  failures  by  testing 
an  item  until  failure  modes  or  events  occur,  identifying  the  failures,  and  then 
fixing  them.  Reliability  growth  is  an  iterative  design  process,  with  five  essential 
elements  that  include:  1)  detection  of  failure  sources,  2)  feedback  of  problems 
identified,  3)  redesign  effort  based  on  problems  identified,  4)  fabrication  of 
hardware,  and  5)  verification  of  redesign  effort  (see  Figure  12).  The  rate  of 
reliability  growth  hinges  on  the  speed  at  which  these  activities  occur,  the 
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significance  of  the  problems,  and  the  effectiveness  of  the  redesign  effort,  with 
any  of  these  activities  acting  as  a  “bottleneck”  to  the  overall  reliability  of  the 
system  (AMSAA,  2000,  September,  pp.  5-6). 


Figure  12.  Reliability  Growth  Feedback  Model  with  Hardware  (From 

AMSAA,  2000,  September,  p.  5) 

The  key  element  to  achieving  a  sufficient  rate  of  growth  is  through 
improvements  to  a  system’s  inherent  reliability  (Chang  et  al. ,  2008,  September, 
p.  270).  Inherent  reliability  is  the  element  of  reliability  that  materiel  developers 
have  control  over,  and  it  refers  to  the  designed  reliability  of  the  system  while 
operating  under  realistic  operating  conditions.  The  objective  of  materiel 
developers  is  to  increase  a  system’s  inherent  reliability  during  the  design  phase 
and  minimize  unforeseen  problems  during  system  testing.  In  the  case  of  MGS, 
the  Muskegon  Technology  Center  handcrafted  the  components  together,  but 
there  was  not  enough  time  for  contractor  systems  integration  testing.  In  effect, 
the  first  two  years  of  the  MGS  development  consisted  of  trial-and-error  tests  for 
reliability. 

D.  PROGRAM  ACTIONS 

Based  on  the  failure  to  pass  reliability  standards  during  PQT,  the  MGS 
PMO  initiated  a  reliability  growth  plan.  After  receiving  the  guidance  of  the 
September  2004  DAB,  the  MGS  PMO  developed  a  new  path  forward  that 
included  a  phased  plan  to  address  the  reliability  issues  (see  Figure  13): 
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•  Phase  I:  Additional  Reliability  Testing  (ART), 

•  Phase  II:  Systems  Engineering  Revitalization,  Management  and 
Process  Improvements,  and 

•  Phase  III:  Redesign  of  the  Ammunition  Handling  System.  (PM  SBCT, 
2006,  p.  59) 

The  MGS  PMO  also  developed  a  Phase  IV  plan  that  emphasized 
survivability  improvements  to  the  Low  Profile  Turret;  however,  that  topic  is 
beyond  the  scope  of  this  case  study. 


Figure  13.  Schedule  for  Phase  l-lll  (From  Fuller,  2004a,  slide  21) 
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1. 


Phase  I:  Additional  Reliability  Testing  (ART) 


Phase  I  served  as  a  time  to  regroup  and  establish  a  new  baseline  for  the 
program.  Prior  to  ART,  GDLS  conducted  a  “contractor  shakedown”  to  ensure 
that  the  MGS  was  “mature  enough”  for  the  Government’s  ART  (PM  SBCT,  2006, 
p.  59).  The  overall  purpose  of  Phase  I  was  to  demonstrate  improvements  to 
reliability  since  the  conclusion  of  PQT  and  to  validate  the  expectations  of 
reliability  growth.  Phase  I,  ART,  consisted  of  two  elements,  pre-ART  and  ART. 
The  MGS  PMO  and  GDLS  conducted  pre-ART  from  November  8-18,  2004  and 
ART  from  December  2004  to  June  2005.  ART  allowed  the  MGS  PMO  and  GDLS 
to  develop  and  validate  the  corrective  actions  for  the  system-abort  modes  that 
evaluators  identified  during  the  2003-2004  PQT. 

Phase  I  also  reestablished  the  MGS  baseline,  and  this  served  as  a 
starting  point  for  the  next  stage  of  testing.  The  actions  taken  during  Phase  I  also 
allowed  the  MGS  PMO  to  review  and  validate  the  new  reliability  growth  plan 
developed  by  GDLS  (Fuller,  2004a,  November  17,  slide  5).  The  MGS  PMO 
conditionally  accepted  the  GDLS  reliability  growth  plan,  which  called  for  monthly 
updates  to  MGS  stakeholders  (Fuller,  2004a,  November  17,  slide  5).  While  ART 
occurred,  GDLS  conducted  a  parallel  effort  to  select  and  conduct  component- 
level  testing  on  a  new  design  for  the  AHS. 

2.  Phase  II:  Systems  Engineering  Revitalization,  Management 
and  Process  Improvements 

The  centerpiece  of  Phase  II  was  the  use  of  a  systems  approach  to 
organize  the  program’s  available  knowledge  and  tools.  Pragmatically,  the  MGS 
PMO  and  GDLS  implemented  the  systems  approach  through  a  “revitalized” 
systems  engineering  plan  (PM  SBCT,  2006,  p.  59).  During  Phase  II,  the  MGS 
PMO  and  GDLS  prepared  the  systems  engineering  plan  for  OSD  approval  in 
January  2005  (Fuller,  2004a,  November  17,  slide  6).  GDLS  also  dedicated  a 
new  team  of  systems  engineers  to  the  MGS  program  for  implementation  of  the 
plan. 
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The  new  systems  engineering  plan  not  only  addressed  the  redesign  of  the 
AHS,  but  it  also  addressed  the  managerial  processes  that  governed  daily 
activities  within  the  program  (Chang  et  al. ,  2009,  March,  p.  152).  Within  GDLS, 
all  of  the  employees  assigned  to  work  on  the  MGS  were  required  to  complete  a 
course  on  Whole  Systems  Architecture  and  Design  Failure  Mode  and  Effects 
Analysis  training  (Josh  King,  GDLS  Stryker  Project  Engineer,  personal 
communication,  10  March  10,  2009).  The  training  provided  the  employees,  who 
came  from  a  broad  range  of  disciplines,  with  a  common  operating  picture  of  how 
GDLS  intended  to  approach  reliability  growth.  The  training  also  ensured  that  all 
of  the  project  engineers  understood  how  to  prioritize  failure  modes  in  the  design 
(Josh  King,  GDLS  Stryker  Project  Engineer,  personal  communication,  March  10, 
2009).  In  a  similar  manner,  PM  SBCT  established  a  40-hour  course  on  systems 
engineering,  and  it  required  this  training  for  all  key  staff  members  (PM  SBCT, 
2006,  p.  34). 


a.  MGS  Integrated  Product  Teams  (IPTs) 

GDLS  reassigned  their  Senior  Director  of  Product  Engineering  to 
be  the  Senior  Director  of  MGS  Engineering.  The  Senior  Director  of  MGS 
Engineering  assumed  central  control  over  all  MGS  engineering  decisions,  and  he 
reassigned  a  number  of  key  employees  to  MGS  full-time  as  Integrated  Product 
Team  (IPT)  leads.  The  MGS  PMO  and  GDLS  required  every  IPT  to  have  a 
technical  manager  and  a  lead  systems  engineer  who  had  responsibility  for  “risk 
management,  configuration  management,  technical  data  management,  and  to 
control  physical  and  functional  interfaces  across  subsystems”  (PM  SBCT,  2006, 
p.  42).  GDLS  assigned  each  of  these  IPT  Leads  to  communicate  with  specific 
government  organizations  such  as  the  user,  materiel  developer,  and  Army 
testers  (Josh  King,  GDLS  Project  Engineer,  personal  communication,  March  10, 
2009).  The  Senior  Director  of  MGS  Engineering  also  institutionalized  a  multi¬ 
disciplinary  IPT  meeting  structure  to  improve  the  flow  of  information  (Josh  King, 
GDLS  Project  Engineer,  personal  communication,  March  10,  2009). 
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In  a  similar  move,  the  government  assigned  personnel  to  each  of 
the  IPTs,  and  the  MGS  PMO  reassigned  one  employee  to  GDLS  on  a  full-time 
basis,  allowing  him  to  participate  in  daily  meetings  to  enhance  the  collaboration 
between  the  government  and  GDLS  (see  Figure  14)  (LTC  Erik  Webb,  personal 
communication,  March  10,  2009).  PM  SBCT  assigned  each  IPT  a  charter  that 
contained  “pre-defined  boundaries  for  decision-making,”  and  the  PM  empowered 
all  of  the  IPTs  to  make  decisions  at  the  lowest  level  possible  (PM  SBCT,  2006,  p. 
32).  PM  SBCT  also  established  a  set  of  weekly  metrics  to  review  issues,  and  it 
made  this  information  available  to  everyone  in  the  program  by  placing  it  into  a 
common  database  known  as  the  Integrated  Data  Environment  (PM  SBCT,  2006, 
p.  34).  The  MGS  IPT  metrics  measured  cost  variance,  schedule  variance,  and 
actual  versus  planned  product  definition  release  (PM  SBCT,  2006,  p.  35). 
Consequently,  communications  among  functional  areas  and  between  the 
government  and  GDLS  occurred  on  a  more  frequent  and  consistent  basis, 
contributing  to  a  collaborative  “team  atmosphere”  (Josh  King,  GDLS  Project 
Engineer,  personal  communication,  March  10,  2009). 


Figure  14.  MGS  IPT  Structure  (From  PM  SBCT,  2006,  p.  31) 


Specific  to  systems  engineering,  PM  SBCT  and  GDLS  instituted  a 
joint  Systems  Engineering  Integration  Team  (SEIT)  with  the  purpose  of 
coordinating  all  systems  engineering  activities  (PM  SBCT,  2006,  p.  36).  The 
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SEIT  had  access  to  over  100  systems  engineers,  and  it  was  “responsible  for 
systems  engineering  technical  management,  including  gate  checkpoint  reviews, 
problem  management,  and  risk  management”  (PM  SBCT,  2006,  p.  36). 

b.  Failure  Prevention  and  Review  Board  and  the  Design 
Actions  and  Reporting  System 

The  MGS  PMO  and  GDLS  also  instituted  a  multi-functional  team  to 
serve  on  a  Failure  Prevention  and  Review  Board  (FPRB)  led  by  the  MGS  PMO. 
The  FPRB  met  twice  per  week,  and  the  MGS  PMO  used  the  FPRB  to  oversee 
the  Design  Actions  Reporting  and  Tracking  System  (DART)  and  all  corrective 
actions.  The  DART  played  a  critical  role  in  that  it  managed  “the  discovered  failure 
modes  as  well  as  associated  corrective  actions”  (Chang  et  al.,  2009,  March,  p. 
152). 

The  DART  served  as  the  primary  reporting  system  for  the  Failure 
Mode  Effects  and  Criticality  Analysis  (FMECA).  With  a  relatively  small  sample 
size  and  a  limited  amount  of  time  available  for  testing,  the  DART  allowed  for 
highly  efficient  identification  and  correction  of  failure  modes  (see  Figure  15).  The 
DART  process  was  highly  effective,  and  it  reduced  the  cycle-time  for  corrective 
actions  on  failure  analysis  from  90  days  to  45  days  (Fuller,  2004b,  December  20, 
slide  8). 
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Figure  15.  Design  Actions  Reporting  and  Tracking  Process  (From  Chang 

et  al.,  2009,  March,  p.  153) 


3.  Phase  III:  Redesign  of  Major  Subsystems  and  Integration 

The  purpose  of  Phase  III  was  to  “demonstrate  reliability  growth  by 
conducting  RGT”  and  to  “redesign  essential  elements  of  the  AHS”  (PM  SBCT, 
2006,  p.  60).  On  October  19,  2004,  GDLS  selected  Western  Design’s  AHS  as 
the  replacement  for  the  Aries  design.  The  new  design  had  a  50%  reduction  in 
parts,  and  it  replaced  the  two  5-round  canisters  with  one  10-round  canister  in  the 
carousel.  In  the  second  and  third  quarters  of  2005,  GDLS  conducted  systems 
integration  of  the  Western  Design  AHS  into  the  MGS  (Fuller,  2004b,  December 
20,  slide  12).  During  this  period,  GDLS  conducted  a  Preliminary  Design  Review 
and  a  Critical  Design  Review  as  part  of  the  reinvigorated  systems  engineering 
process  for  the  new  AHS  as  well  as  other  design  changes  for  the  MGS  (Fuller, 
2004b,  December  20,  slide  13).  Soon  thereafter,  GDLS  conducted  a  short 
“contractor  shakeout”  test  in  June  to  August  2005,  with  government  participation 
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to  determine  the  level  of  system  reliability  (Chang  et  al. ,  2008,  September,  p. 
269).  The  actual  reliability  during  contractor  shakeout  was  57  MRBSA,  short  of 
the  threshold  requirement  of  81  (Kim  McCormick,  GDLS  PM  MGS,  personal 
communication,  January  22,  2009).  The  MGS  PMO  determined  that  the 
Production  Verification  Test  (PVT)  would  need  to  serve  as  an  additional  reliability 
growth  test  (Kim  McCormick,  GDLS  PM  MGS,  personal  communication,  January 
22,  2009). 

PVT  began  in  May  2006  and  finished  in  April  2008  with  three  production¬ 
like  vehicles  (Chang  et  al.,  2009,  March,  p.  155).  The  actual  reliability  growth 
rate  significantly  exceeded  the  expected  growth  rate  (38%  versus  22%), 
demonstrating  the  effectiveness  of  the  methodology  developed  in  Phase  I  and  II. 
The  actual  reliability  during  PVT  was  104  MRBSA,  which  exceeded  the  threshold 
requirement  (Kim  McCormick,  GDLS  PM  MGS,  personal  communication, 
January  22,  2009).  When  viewed  in  comparison  to  the  13  MRBSA  in  PQT,  the 
improvement  is  substantial.  It  took  the  crisis  of  September  2004  to  shift  the  MGS 
program  from  a  series  of  incremental  changes  to  a  dramatic  restructuring  built 
around  the  systems  approach. 

E.  RISK  MANAGEMENT  PROCESS 

The  Stryker  acquisition  strategy  attempted  to  minimize  overall 
programmatic  risk  by  using  NDI  and  “near-NDI”  (PM  SBCT,  2006,  p.  106).  As 
part  of  the  March  2000  acquisition  strategy,  the  PM  SBCT  identified  risk  on  a  “top 
level  in  terms  of  program  cost,  schedule,  and  technical  performance  to  allow 
informed  decision-making”  (PM  SBCT,  2006,  p.  106).  After  the  revitalization  of 
the  systems  engineering  approach  in  2004-2005,  PM  SBCT  integrated  risk  into 
the  systems  engineering  process  with  an  effort  to  identify  risk  from  the  “bottom 
up”  and  from  “top  down  perspectives”  (PM  SBCT,  2006,  p.  106).  PM  SBCT  and 
GDLS  made  use  of  the  information  derived  from  all  collaborative  groups  to 
include  the  IPTs,  the  systems  engineering  risk  team,  and  a  risk  review  board  in 
identifying  risk  and  developing  integrated  solutions. 
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PM  SBCT  and  GDLS  initiated  a  process  where  they  formally  discussed 
risk  at  all  program  reviews  and  program  milestones.  Additionally,  PM  SBCT  and 
GDLS  made  all  risk  documentation  available  to  stakeholders  on  the  common  IDE 
database  (PM  SBCT,  2006,  p.  107).  While  PM  SBCT  was  responsible  for 
oversight  of  the  risk  management  process,  GDLS  served  as  the  primary  manager 
for  technical  risk  (PM  SBCT,  2006,  p.  106).  PM  SBCT  and  GDLS  not  only 
shared  risk,  but  they  also  used  a  common  risk  management  process  that 
assessed  risk  on  a  continuous  basis  (see  Figure  16).  The  next  section  examines 
the  MGS  from  the  perspective  of  complexity. 


Figure  16.  PM  SBCT  Risk  Management  Process  (From  PM  SBCT,  2006,  p. 

106) 


F.  COMPLEXITY  AND  THE  MGS 

The  literature  review  in  Chapter  II  demonstrates  that  there  are  common 
properties  to  complex  programs.  What  makes  a  program  complex  is  not  only  the 
internal  technical  complexity  of  the  system  but  also  the  upstream  complexity  that 
originates  from  the  outer  environment.  Based  on  this  perspective,  the  MGS 
certainly  qualifies  as  a  complex  program. 
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While  the  people  who  worked  on  the  MGS  program  were  extremely 
capable  and  dedicated  to  the  program’s  success,  the  MGS  still  encountered 
numerous  difficulties  that  resulted  from  organizational,  environmental,  and 
technical  forces  that  affected  the  program.  One  way  to  explain  the  program  is  by 
describing  it  in  terms  of  Simon’s  model  of  complexity  described  in  Chapter  II. 

The  complexity  of  the  outer  environment  created  uncertainty  and,  in  the 
process,  increased  the  MGS  program’s  overall  level  of  risk.  The  MGS  program, 
representing  the  inner  environment,  was  in  a  search  to  find  an  approach  to 
manage  the  complexity  and  uncertainty  that  it  faced.  The  next  section  addresses 
the  outer  and  inner  environments,  and  it  provides  an  analysis  of  how  the  MGS 
PMO  managed  complexity. 

1.  The  Outer  Environment 

According  to  Simon  (1981)  and  Kauffman  (1993),  all  complexity  originates 
outside  of  a  system,  and,  in  the  case  of  the  MGS,  the  outer  environment 
represents  all  factors  that  directly  and  indirectly  had  an  impact  on  the  MGS.  Six 
risk  factors  stand  out  in  this  category  including:  1 )  the  strategic  uncertainty  of  the 
post-Cold  War  era,  2)  time-based  acquisition  strategy,  3)  the  unintended 
consequences  of  the  acquisition  reforms  of  the  1990s,  4)  the  common 
developmental  and  non-developmental  acquisition  strategy,  5)  the  categorization 
of  MGS  as  NDI,  and  6)  the  focus  on  vehicle  commonality  (see  Figure  17).  These 
risk  factors  fall  under  one  of  three  areas  of  criticality  based  upon  information 
adequacy:  1)  known-known,  2)  unknown-known,  and  3)  unknown-unknown.  All 
of  these  factors  are  interrelated,  but  the  inexact  and  unknown  causality  of  this 
relationship  is  what  made  the  MGS  program  complex. 
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a.  Environmental  Risk  Factors 

At  the  center  of  General  Shinseki’s  ladder  of  inference  was  the 
uncertainty  of  the  new  multi-polar  world.  Unlike  the  bipolar  world,  the  United 
States  could  no  longer  predict  with  any  accuracy  the  actions  of  its  adversaries. 
The  post-Cold  War  period  demonstrated  that  the  United  States  required  the 
flexibility  of  inserting  a  medium-size  formation  anywhere  in  the  world  within  96 
hours,  with  the  ability  to  address  a  continuum  of  operations  ranging  from 
humanitarian  aid  to  major  combat.  The  period  from  1990-2008  demonstrated 
that  this  risk  area  was  clearly  positioned  in  the  category  of  an  unknown-unknown. 
Strategic  uncertainty  drove  the  Army’s  Transformation  strategy  and  the  time- 
based  acquisition  strategy. 
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b.  Organizational  Risk  Factors 

General  Eric  Shinseki,  the  champion  of  the  Army’s  Transformation 
strategy,  understood  that  this  strategy  was  a  long-term  endeavor,  and  Stryker 
was  merely  the  first  increment  of  change.  Beyond  the  technological  challenges 
of  transformation,  he  soberly  determined  that  the  single  biggest  obstacle  to  Army 
Transformation  was  the  need  to  overcome  the  Army’s  own  byzantine 
bureaucracy.  As  the  decisive  point  of  the  Transformation  strategy,  he 
determined  that  Stryker  required  a  time-based,  rather  than  an  event-based, 
strategy  to  achieve  “irreversible  momentum”  (Shinseki,  2003).  With  a  specific 
date  for  initial  operational  capability,  this  risk  factor  falls  under  the  known-known 
category. 

In  retrospect,  a  two-year  development  period  for  a  vehicle  that 
required  extensive  systems  integration  may  seem  unreasonable;  yet  when 
viewed  from  the  assumption  that  the  MGS  was  close  to  ready  and  from  the 
strategic  perspective  of  General  Shinseki,  its  rationale  seems  more  apparent. 
The  March  2000  Acquisition  Strategy  Report  for  the  Interim  Armored  Vehicle 
served  as  the  over-arching  strategy  for  the  developmental  and  non- 
developmental  IAV  variants,  but  the  strategy  did  not  adequately  address  the 
technical  risk  associated  with  the  MGS  and  NBCRV,  particularly  with  integrating 
multiple  Non-Developmental  Items  and  Government  Furnished  Equipment  in  a 
relatively  short  time  period.  The  Acquisition  Strategy  Report  for  the  Interim 
Armored  Vehicle  stated  in  several  cases  that  “limited  development  activity  may 
occur,”  and  this  did  not  take  into  account  the  tremendous  challenges  associated 
with  systems  integration  (PM  BCT,  2000,  p.  10). 

As  an  integrative  approach  for  all  program  activities,  the  March 
2000  acquisition  strategy  was  overly  focused  on  the  eight  production  models. 
Ultimately,  this  led  the  program  to  leave  out  critical  developmental  steps  such  as 
systems  integration  in  the  interest  of  time.  The  importance  of  the  systems 
integration  process  is  crucial  to  risk  mitigation  because  it  reveals  unpredictable 
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interactions  between  components  and  validates  the  technical  assumptions.  The 
acquisition  strategy  clearly  had  a  strong  relationship  to  the  MGS  PMO’s 
assumptions  on  NDI. 

The  unintended  consequences  of  the  acquisition  reforms  initiated 
by  Dr.  William  Perry  in  the  1990s  also  affected  the  MGS.  A  broad  assessment  of 
these  reforms,  particularly  the  long-term  cost  savings,  is  beyond  the  scope  of  this 
case  study.  The  DoD  intended  to  improve  the  effectiveness  and  reduce  the 
cycle-time  of  defense  acquisitions  through  the  use  performance-specification 
reforms,  but,  in  the  early  stages  of  their  execution,  they  had  the  potential  to 
increase  the  government’s  level  of  risk  because  of  the  disengagement  from  the 
contractor  (Yoder,  2004,  p.  2).  While  the  emphasis  on  performance-oriented 
specifications  provided  the  contractor  with  more  latitude  for  innovation,  it  also 
created  the  potential  for  increased  risk  if  the  government  did  not  identify  an 
effective  verification  plan  to  accompany  the  performance  specifications.  The 
difficulty  of  obtaining  waivers  contributed  to  the  government’s  disengagement 
from  the  contractor  because  the  government  had  to  put  increased  faith  in  a  well 
thought  out  verification  plan  that  it  stipulated  in  the  EMD  contract,  and  on  the 
engineering  approach  taken  by  the  contractor.  The  government  wrote  the  MGS 
EMD  contract  with  performance-based  requirements  and  a  nearly  complete 
absence  of  military  specifications  and  standards,  and  the  EMD  contract  did  not 
call  out  specific  requirements  for  component-level  reliability  testing  with  a 
systems  engineering  process  (N.  Jenny  Chang,  TACOM  Reliability  Engineer, 
personal  communications,  March  4,  2008). 

c.  Technical  Risk  Factors 

The  outer  environment  included  two  technical  risk  factors  that  were 
strongly  interrelated:  1)  the  user  focus  on  vehicle  commonality  and  2)  the 
categorization  of  MGS  as  NDI.  What  made  the  MGS  requirement  particularly 
challenging  was  the  user  emphasis  on  commonality.  Individually,  the  Army  could 
have  optimized  on  performance  and  reliability  by  developing  separate  pieces  of 
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equipment;  however,  the  emphasis  on  commonality  was  a  new  concept, 
especially  given  the  competing  requirements  of  transportability  and  lethality.  The 
Army  was  looking  for  a  common  vehicle  to  perform  a  wide  range  of  tasks; 
however,  the  implementation  of  this  concept  proved  to  be  a  challenge.  GDLS 
seemed  to  provide  the  optimal  solution  for  the  commonality  requirement  with  its 
105mm  equipped  LAV  III  that  initially  appeared  to  be  a  non-developmental  item. 

General  Shinseki’s  intent  was  to  field  a  medium-force  capability  that 
consisted  of  off-the-shelf  solutions.  The  emphasis  on  an  off-the-shelf  solution 
was  a  central  element  of  the  acquisition  reforms  of  the  1990s  described  in  the 
organizational  risk  factors.  Although  the  MGS  consisted  of  NDI  components 
such  as  the  chassis,  C4ISR  equipment,  the  low  profile  turret,  and  the  Aries  AHS, 
GDLS  did  not  have  an  integrated  solution  at  the  time  of  the  contract  award.  The 
categorization  of  the  MGS  as  NDI  was  somewhat  misleading  because  it  did 
require  significant  modification.  Although  the  NDI  and  commonality  assumptions 
caused  significant  problems  during  development,  both  of  these  assumptions 
were  closer  to  being  a  known-known  rather  than  an  unknown-known.  In  terms  of 
information  adequacy,  the  design  of  the  time-based  acquisition  strategy  caused 
the  Army  to  overemphasize  speed. 

2.  The  Inner  Environment 

One  can  look  at  the  MGS  program  symbolically  as  a  “box  within  a  box” 
that  had  to  adapt  to  the  risk  factors  of  the  dynamic  outer  environment  (Simon, 
1981,  p.  148).  The  MGS  PMO  worked  in  an  environment  of  considerable 
uncertainty  while  facing  a  time-based  acquisition  strategy.  The  objective  of  the 
inner  environment  is  to  achieve  a  sense  of  resilience  or  homeostasis.  Through  a 
series  of  self-organizing  actions,  the  MGS  PMO  attempted  to  adapt  the  MGS 
program  to  the  risk  factors  of  the  outer  environment. 

The  new  approach  consisted  of  three  inseparable  elements  that  enabled 
the  MGS  program  to  manage  the  complex  environment:  1 )  systems  approach,  2) 
error-embracing  behavior,  and  3)  collaborative  learning.  Although  the  systems 
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approach  is  the  decisive  effort,  it  required  the  complementary  effects  of  the  two 
shaping  efforts,  error-embracing  behavior  and  collaborative  learning. 

3.  Systems  Approach 

The  interdependent  variables  of  the  outer  environment  are  difficult  to 
separate  and  analyze  as  snapshots  in  time.  For  this  reason,  the  decisive  effort  of 
managing  complexity  is  the  systems  approach.  The  systems  approach  attempts 
to  view  the  entire  system  in  a  holistic  manner  while  coordinating  people  and 
processes.  The  problem  of  uncertainty  becomes  more  difficult  with  acquisition 
programs  that  require  the  rapid  integration  of  technology  in  a  short  time  period. 

Initially,  the  program  operated  under  the  assumption  that  the  MGS  would 
only  require  limited  development.  The  MGS  program  viewed  the  use  of  systems 
engineering  as  either  unnecessary  or  too  time-consuming.  As  it  became 
increasingly  evident  that  the  program  would  not  meet  the  initial  schedule  and 
performance  objectives,  the  use  of  systems  engineering  became  a  necessity. 

Until  2004,  the  schedule  consisted  of  a  series  of  tests  (PQT)  that 
disproved  all  of  the  flawed  assumptions  from  the  beginning  of  the  program. 
Rather  than  provide  the  Army  with  a  well-integrated  system  in  2002,  GDLS  used 
the  “big  bang”  approach  to  systems  integration  by  piecing  together  all  of  the  sub¬ 
systems  at  the  same  time  (Hyunh,  2008,  slide  20).  The  systems  engineering 
process  adopted  by  the  MGS  PMO  and  GDLS  revealed  that  systems  integration 
takes  time  and  requires  a  disciplined  process. 

What  the  MGS  PMO  clearly  understood  was  that  the  consequences  of 
proceeding  down  the  original  trial-and-error  approach  were  clearly  not  producing 
the  desired  result.  The  area  in  which  this  approach  demonstrated  unmistakable 
progress  was  in  reliability  growth  for  the  AHS  (see  Figure  18). 
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Test  Event 

Date 
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Reliability 
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Actual 

Reliability 
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Approach 
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Qualification  Testing 
(PQT) 
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13 

-Original  configuration 
-No  component  level  testing 
-Trial  8>  error  approach  leads 
to  program  crisis 

Pre -Additional 
Reliability  Testing 
(Pre-ART) 

SEP-OCT  04 

17 

36 

-Corrective  Actions  on  original 
configuration 
-Transition  to  systems 
engineering 

Additional  Reliability 
Testing 
(ART) 

NOV  04^JUN  05 

27.8 

N/A 

-Corrective  Actions  on  original 
configuration 
-Continue  transition  to 
systems  engineering 

Reliability  Growth 
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JUL-AUG  05 

44-55 

57 

-New  AHS  installed 

-Use  of  systems  engineering 

Production 
Verification  Testing 
(PVT) 

2006 

81 

104 

-Production  Configuration 
-Integrated  strategic  activities 

Figure  18.  Reliability  Growth  over  Time  (From  GDLS,  2009) 


In  the  trial-and-error  approach,  the  MGS  PMO  hoped  to  achieve  success 
during  a  relatively  short  PQT;  however,  this  was  a  nearly  impossible  expectation. 
The  implementation  of  a  systems  engineering  approach  played  a  major  role  in 
reducing  the  program’s  overall  level  of  risk;  in  turn,  this  strengthened  the  Defense 
Acquisition  Board’s  (DAB)  confidence  in  the  program  (Wynne,  2004,  p.  2).  In 
complex  programs  that  require  personnel  from  multiple  disciplines — such  as  the 
MGS — the  use  of  systems  engineering  is  critical  to  address  problems  from 
multiple  perspectives  with  a  holistic  perspective. 

4.  Collaborative  Learning 

When  developing  a  complex  system,  the  effect  of  social  influences, 
particularly  collaboration,  becomes  increasingly  important  because  one  of  the 
primary  issues  that  arises  is  the  lack  of  communication  and  knowledge 
dissemination  between  stakeholders  (Prencipe,  Davies,  &  Hobday,  2005,  p.  49). 
The  systems  engineering  process  takes  social  influences  into  account  with  its 
emphasis  on  interdisciplinary  collaboration. 
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The  organizational  adaptations  to  accommodate  the  reliability  growth  plan 
(FPRB  and  DART)  demonstrated  the  need  for  organizations  to  be  highly 
proficient  at  monitoring  and  acting  on  the  rapid  flow  of  information.  The 
effectiveness  of  collaborative  learning  demonstrates  that  the  free  flow  of 
information  is  possible  if  the  program  leadership  establishes  a  culture  that 
identifies  and  eliminates  defensive  barriers. 

One  reason  that  the  MGS  PMO  and  GDLS  took  hold  of  collaborative 
learning  was  that  the  program  reached  the  crisis  point.  Defensive  barriers  came 
down,  and  both  the  MGS  PMO  and  GDLS  saw  it  as  an  opportunity  to  get  the 
program  on  track.  In  this  case,  the  crisis  period  of  late  2004  served  as  an 
innovation  opportunity  for  both  GDLS  and  the  MGS  PMO  to  establish  a  new 
learning  network  (see  Figure  19). 
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Figure  19.  Example  of  Collaborative  Learning  (From  GDLS,  2007,  slide  5) 
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Additionally,  complex  programs  must  deal  with  information  that  falls  under 
the  known-known,  unknown-known,  and  unknown-unknown  categories.  Risk 
management  is  practical  with  known-known  and  unknown-known  information,  but 
it  is  not  as  effective  with  unknown-unknown  events  because  these  events  are 
almost  impossible  to  predict.  That  is  one  reason  why  it  is  essential  for 
organizations  to  have  a  collaborative  learning  capacity  that  enables  them  to 
adapt  to  unpredictable  situations.  The  capability  for  organizations  to  adapt  to  ill- 
structured  and  unpredictable  problems  makes  collaborative  learning  a  critical  and 
complementary  effort  to  the  systems  approach  and  to  error-embracing  behavior. 
The  use  of  the  Failure  Prevention  and  Review  Board  (FPRB)  and  IPTs 
demonstrated  that  reduction  of  cycle-time  with  the  reliability  growth  is  possible 
through  a  collaborative  and  disciplined  effort. 

Recognizing  the  importance  of  social  factors  in  the  implementation  of 
systems  engineering,  the  MGS  PMO  and  GDLS  realigned  their  organizations  in 
late  2004  to  improve  their  level  of  collaboration  and  ability  to  implement  the 
systems  engineering  process.  However,  the  systems  approach  and  collaborative 
learning  requires  a  culture  where  the  program  leadership  rewards  individuals  for 
identifying  problems  and  developing  integrated  solutions. 

5.  Systematic  Error-embracing  Behavior 

An  overall  strategy  that  integrates  the  use  of  systematic,  error-embracing 
behavior  with  the  systems  approach  and  collaborative  learning  provides  a 
complex  program  with  the  means  of  determining  how  components  and  sub¬ 
systems  will  interact.  Initially,  the  MGS  PMO  and  GDLS  development  approach 
was  to  simultaneously  bring  many  components  together  and  hope  that  the  tests 
were  successful.  As  it  became  more  apparent  that  the  design  was  immature,  the 
primary  method  to  reduce  the  knowledge  gap  between  actual  and  expected 
performance  was  to  seek  error-embracing  behavior  in  the  form  of  identifying  and 
correcting  failure  modes. 
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The  MGS  PMO  developed  a  path  for  reliability  growth  that  started  with 
pre-ART  and  concluded  with  PVT.  The  MGS  PMO  applied  the  lessons  learned 
from  PQT  by  going  directly  to  systems-level  testing  and  then  conducting  a  series 
of  component-level  tests  on  the  new  Western  Design  AHS  and  other  design 
improvements.  One  reason  that  the  reliability  growth  was  so  successful  in  2005- 
2006  was  the  systematic  identification  of  failure  modes.  The  MGS  PMO  and 
GDLS  identified  failure  modes  in  a  small  enough  scope  to  diagnose  them  and 
develop  corrective  actions  in  a  methodical  manner. 

G.  CONCLUSION 

To  the  outside  observer,  it  may  seem  as  though  the  Army  and  GDLS  did 
not  exercise  enough  due  diligence  with  the  development  of  the  MGS.  In 
retrospect,  no  one  is  omniscient  and  individuals  have  tremendous  difficulty  in 
making  objective  comparisons  across  multiple  options  while  trying  to  figure  out 
the  consequences  of  those  decisions  (Simon,  1979,  September,  p.  502).  In 
Judgment  Under  Uncertainty,  Tversky  and  Kahneman  also  discussed  this 
concept  when  they  said, 

People  rely  on  [a]  limited  number  of  heuristic  principles,  which 
reduce  the  complex  tasks  of  assessing  probabilities  and  predicting 
values  to  simpler  judgmental  operations.  In  general,  these 
heuristics  are  quite  useful,  but  sometimes  they  lead  to  severe  or 
systematic  errors.  (1974,  September  27,  p.  1124) 

A  perfect  adaptation  to  the  outer  environment  is  nearly  impossible  for 
many  reasons  but  mainly  because  the  decision-makers,  the  MGS  PMO  in  this 
case,  were  operating  under  uncertainty.  To  make  the  best  decisions  possible, 
the  decisionmakers  needed  as  much  fact-based  information  as  possible  to 
establish  their  baseline.  With  the  MGS,  the  Army  initiated  the  program  with 
imperfect  information  based  on  inaccurate  assumptions  in  the  interest  of  time. 
The  future  occurrence  of  a  similar  situation  is  preventable  if  the  lessons  learned 
are  properly  absorbed. 
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There  is  no  simple  answer  to  a  root-cause  analysis  on  the  troubled 
development  period  of  the  MGS  from  2001-2008.  It  seems  evident  that  the  Army 
and  GDLS  satisficed  in  their  development  strategy  to  meet  the  time-to-market 
requirements.  Moving  beyond  the  actual  system  reliability,  this  case  study 
looked  at  the  structure  of  processes  to  determine  how  an  overestimation  of  the 
system  reliability  occurred. 

In  effect,  the  government  made  decisions  early  on  about  the  length  of  the 
schedule  and  the  test  approach  that  did  not  reflect  the  technical  status  of  the 
system,  and  the  government  anchored  these  decisions  on  inaccurate 
assumptions  about  the  MGS.  In  retrospect,  it  appears  that  the  Army  started  off 
with  a  tendency  for  unwarranted  optimism  that  the  MGS  PMO  and  GDLS  could 
field  the  system  on  the  original  schedule.  That  optimism  did  not  take  into 
account  the  lesson  that  time-to-market  is  not  free  and  systems  integration  takes 
time.  The  last  two  chapters  demonstrated  that  a  rigorous  and  well -resourced 
systems  engineering  process  is  the  most  effective  way  to  reduce  technical  risk  in 
the  face  of  uncertainty. 

All  of  this  points  to  the  need  for  organizations  to  deal  with  uncertainty, 
particularly  within  complex  systems.  Within  defense  acquisition,  the  solution  to  a 
problem  is  not  only  dependent  upon  the  objective  information  provided  to  the 
decision-maker  but  also  upon  the  type  of  process  that  the  decision-maker  uses. 
A  decision  maker  must  determine  what  he  or  she  knows  about  a  system  and 
must  then  determine  how  much  information  is  sufficient,  given  their  availability  of 
time  and  resources.  The  next  chapter  addresses  the  lessons  learned  from  the 
MGS  case  study  on  managing  complexity. 
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VI.  CONCLUSION  AND  LESSONS  LEARNED 


A.  INTRODUCTION 

One  of  the  stated  goals  of  the  Defense  Acquisition  System  (DAS)  is  to 
provide  users  with  “effective,  affordable,  and  timely  systems”  that  are  developed 
in  “response  to  an  approved  need”  (Under  Secretary  of  Defense  (AT&L),  2003a). 
The  Army  provides  program  managers  with  a  charter  to  field  these  systems  given 
cost,  schedule  and  performance  constraints  while  navigating  a  complex 
environment.  The  difficulty  in  fielding  systems  stems  from  the  complex 
environment  found  in  the  defense  acquisition  system.  The  environment  is 
complex  because  of  the  difficulty  in  determining  how  the  risk  factors  are 
interrelated.  Environments  that  encounter  a  greater  degree  of  complexity  and 
uncertainty  will  also  experience  an  increase  in  their  overall  level  of  program  risk. 
The  MGS  case  study  attempts  to  document  how  one  program  managed  that 
complex  environment. 

“Manage”  is  the  key  term  because  program  managers  cannot  eliminate 
uncertainty  and  complexity,  but  they  can  manage  it,  if  they  have  an  adequate 
strategy  in  place.  In  Embracing  Uncertainty,  Clampitt  and  DeKoch  (2001) 
describe  five  methods  for  creating  certainty  that  include  gut  instincts, 
experiences,  reasoning,  and  testing  (p.  47).  Yet,  in  their  analysis,  they  debunk 
the  notion  that  one  can  eliminate  uncertainty  in  decision-making  (Clampitt  and 
DeKoch,  2001,  p.  28).  In  The  Fifth  Discipline,  Senge  discusses  the  misleading 
notion  that  effective  managers  must  have  an  omniscient  picture  of  what  is 
occurring  around  them  at  all  times  when  he  said: 

it  is  simply  unacceptable  for  managers  to  act  as  though  they  do  not 

know  what  is  causing  a  problem[...]Those  intent  on  reaching  such 

positions  learn  early  on  to  develop  an  air  of  confident  authority. 

(2007,  p.  234) 

This  case  study  makes  it  evident  that  charting  a  course  of  certainty  in  all 
but  the  most  simple  acquisition  programs  is  not  possible  given  the  tremendously 
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complex  environment  faced  by  today’s  program  managers.  The  MGS  program 
experienced  complexity  in  terms  of  organization,  environment,  and  technology.  It 
is  no  surprise  that  program  managers  frequently  use  the  cliche  “it  depends”  when 
describing  a  solution  to  a  problem.  The  program  manager  does  not  base  his  or 
her  response  on  a  scientific  analysis  of  the  problem,  but,  rather,  the  program 
manager  bases  the  response  on  years  of  observing  unpredictable  interactions 
between  complex  events. 

Although  the  pursuit  of  absolute  certainty  is  a  quixotic  program  objective,  a 
more  pragmatic  objective  for  program  managers  is  the  management  of 
complexity.  What  follows  is  a  restatement  of  this  case  study’s  research  question, 
a  discussion  of  the  core  findings,  and  a  modest  list  of  lessons  learned. 

B.  RESEARCH  PROBLEM 

The  primary  research  problem  was  to  find  a  significant  developmental 
problem  experienced  with  the  MGS  and  then  to  analyze  the  root  causes  of  the 
problem  as  well  as  the  corrective  actions  taken  by  the  MGS  Product 
Management  Office  (MGS  PMO).  Parallel  to  this  effort,  this  case  study  explored 
complexity  theory  to  determine  if  it  was  applicable  to  the  MGS  program.  After 
conducting  the  analysis,  this  case  study  attempted  to  draw  insights  on  how  the 
MGS  program  managed  complexity  and  then  to  determine  what  lessons  one 
could  apply  to  other  acquisition  programs. 

C.  FINDINGS  AND  APPLICATION 

1.  Findings 

The  Army  planned  to  acquire  the  MGS  under  an  accelerated,  time-based 
acquisition  strategy.  However,  the  acquisition  strategy  did  not  achieve  the  early 
fielding  of  the  MGS,  which  was  one  of  the  Army’s  primary  objectives.  The 
acquisition  strategy  is  the  “high  level  business  and  technical  management 
approach  designed  to  achieve  program  objectives  within  required  resource 
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constraints”  (DSMC,  1999,  1-1),  but  the  IAV  acquisition  strategy  did  not  account 
for  the  technical  difficulties  encountered  in  transitioning  from  the  early  MGS 
variants  to  the  production  version. 

The  Army  took  a  number  of  steps  to  mitigate  program  risk  to 
accommodate  the  time-based  acquisition  strategy.  In  1999,  the  Army  conducted 
a  Platform  Performance  Demonstration  (PPD)  to  determine  the  “state  of  the  art,” 
and  it  used  the  information  gained  from  the  PPD  to  refine  the  requirements  and 
develop  the  Request  for  Proposal  (RFP).  The  Army  also  mandated  that  the  MGS 
use  NDI  components  to  limit  the  amount  of  development  required. 

Despite  the  steps  taken  to  reduce  programmatic  risk,  the  MGS  still 
required  a  considerable  amount  of  development.  It  was  not  until  2002  that  the 
Army  realized  that  there  was  a  gap  between  the  expected  or  anticipated 
performance  of  the  MGS  and  its  actual  performance.  The  early  MGS  variants 
were  less  technically  mature  than  anticipated,  and  this  required  additional  time 
for  development  and  testing. 

What  makes  the  MGS  program  interesting  as  a  case  study  was  the  rate  of 
improvement  in  the  MGS  reliability  after  the  strategic  approach  changed.  This 
case  study  used  the  MGS  reliability  problems  as  a  microcosm  for  analyzing  how 
a  contemporary  acquisition  program  self-organized  to  increase  its  adaptation  to 
complexity.  During  the  crisis  period  of  2004-2005,  the  MGS  PMO  adopted  a 
systems  approach  complemented  by  error-embracing  behavior  and  collaborative 
learning. 

The  systems  approach  adopted  by  the  MGS  PMO  and  GDLS  improved 
the  capacity  of  the  program  to  self-organize  when  the  complex  environment 
around  the  program  was  constantly  changing.  The  MGS  PMO  realized  that  the 
technical  progress  of  the  vehicle  was  out  of  alignment  with  the  acquisition 
strategy,  and  it  took  steps  to  redefine  the  strategy  through  the  integration  of  the 
systems  approach,  error-embracing  behavior,  and  collaborative  learning. 

Based  on  the  information  available,  the  case  study  concluded  that 
intensive  programmatic  crises  occurs  when  an  acquisition  strategy  does  not 
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adequately  synchronize  critical  program  activities  such  as  risk  management, 
systems  engineering,  test  and  evaluation,  contract  management,  and  integrated 
product/process  development.  These  factors  strongly  correlate  to  the  success 
factors  that  are  associated  with  the  actions  taken  by  the  MGS  PMO  and  GDLS 
(see  Figure  20). 


Insights  from  MGS  Strategic  Activities 


Acquisition  Strategy:  Align  approach  and  processes 
in  a  complementary  manner  to  the  situation 


Figure  20.  MGS  PMO  Strategic  Approach 

Programs  that  embrace  a  systems  approach  complemented  by  error¬ 
embracing  behavior  and  collaborative  learning  are  capable  of  accepting  greater 
degrees  of  risk  associated  with  uncertainty  and  complexity.  These  concepts  are 
not  new.  In  fact,  defense  acquisition  doctrine  has  a  deep  and  broad  array  of 
explicit  knowledge  available  to  acquisition  programs  that  discusses  these 
concepts,  but  it  is  unclear  how  of  much  of  this  doctrine  is  adhered  to. 
Furthermore,  it  is  unclear  if  lessons  learned  from  other  programs  such  as  the 
Army’s  Sergeant  York  air  defense  system,  the  Navy’s  T-45  flight  trainer,  and  the 
Army’s  Armed  Reconnaissance  Helicopter  are  fully  absorbed  by  the  acquisition 
community. 
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2.  A  Strategic  Approach  is  Necessary  to  Manage  Complexity 

External  and  internal  complexity  results  in  increased  downstream  levels  of 
uncertainty  for  acquisition  programs.  Managing  uncertainty  is  possible  through 
continuous  strategic  planning  that  ascertains  the  level  of  information  available 
from  the  environment  and  integrates  program  activities  to  achieve  objectives 
while  recognizing  resource  constraints.  Over  time,  the  problems  caused  by 
complexity  will  change,  and  the  program  manager  must  make  corresponding 
adjustments  to  the  strategy.  Between  2000  and  2006,  the  MGS  PMO  self- 
organized  to  improve  the  alignment  and  fit  of  their  strategic  activities  (see  Figure 
21). 
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Figure  21.  MGS  Acquisition  Strategy  Alignment  over  Time 


How  does  a  program  manager  proactively  determine  the  strategic 
approach?  It  is  essential  to  point  out  that  acquisition  strategy  is  not  a  static 
program  document  that  the  program  manager  updates  at  key  milestones.  Rather 
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acquisition  strategy  is  a  continuous  process  that  the  program  manager  uses  to 
integrate  all  elements  of  his  or  her  program,  while  recognizing  the  risk  and 
uncertainty  in  the  complex  environment. 

The  key  elements  of  an  acquisition  strategy  will  not  align  by  default. 
Rather,  self-organization  is  an  adaptation  to  complexity  that  requires  significant 
effort  and  foresight.  The  program  manager  should  start  with  the  program’s 
internal  and  external  goals,  and  then  align  the  program’s  activities  to  fit  those 
goals.  After  achieving  some  alignment,  the  program  manager  will  need  to 
reinforce  the  fit  between  elements.  Therefore,  the  program  manager  must  often 
take  on  the  roles  of  an  orchestrator  and  synchronizer. 

3.  Integration  of  Strategic  Activities 

The  difference  in  program  outcome  could  originate  from  the  program 
manager’s  ability  to  develop  an  acquisition  strategy  that  adapts  to  the 
environment  through  the  alignment  and  fit  of  its  strategic  activities.  The 
acquisition  strategy  should  serve  as  a  means  to  coordinate  the  work  of  all 
individuals  who  work  for  or  with  the  program.  As  a  dynamic  planning  document, 
it  should  ensure  that  the  program’s  activities  reinforce  one  another  and  are 
consistent. 

With  acquisition  strategy,  the  whole  matters  more  than  any  individual 
activity.  At  the  core  of  strategic  planning  for  acquisition  programs  is  the 
alignment  of  these  five  elements:  integrated  product/process  development,  risk 
management  systems  engineering,  test  and  evaluation,  and  contract 
management.  There  is  no  cookie-cutter  approach  or  template  for  strategy 
implementation  because  each  case  is  unique.  When  properly  tailored  to  a 
common  strategic  vision,  these  activities  become  powerful  tools  to  manage 
complexity. 


a.  Integrated  Product/Process  Development  (IPPD) 

The  use  of  Integrated  Product/Process  Development  provides  the 
overarching  linkage  between  the  strategic  activities  because  it  enables 
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collaborative  learning  and  cross-functional  communication.  A  key  element  of 
IPPD  is  the  use  of  multi-disciplinary  Integrated  Product  Teams  (IPTs).  The  use 
of  these  teams  is  essential  because  each  stakeholder  provides  a  unique  frame  of 
reference  and  set  of  assumptions.  Within  the  acquisition  strategy,  the  program 
manager  must  properly  orient  and  challenge  the  IPTs  towards  program 
objectives  and  empower  them  to  reduce  defensive  barriers  between  functions 
and  organizations  (DSMC,  1999,  p.  2-3). 

An  IPT  system  and  a  program  culture  that  emphasize  collaborative 
learning  will  also  help  a  program  adapt  to  unknown-unknown  risk  factors. 
Unknown-unknown  events  can  strike  a  program  without  warning,  and  a 
program’s  ability  to  quickly  adapt,  learn,  and  develop  collaborative  solutions 
provides  the  most  effective  means  to  adapt  to  this  type  of  risk  factor.  The  IPTs 
serve  as  the  facilitators  of  all  strategic  activities  for  the  program. 

b.  Risk  Management 

The  risk  management  process  is  dependent  upon  the  program’s 
IPTs  because  the  program  requires  multiple  perspectives  for  risk  identification. 
The  DoD  Risk  Management  Guide  clearly  states  that  risk  identification  is  the 
responsibility  of  all  members  of  the  IPT,  and  it  does  not  solely  rest  with  the 
program  manager  or  with  the  lead  systems  engineer  (DoD,  August,  2006,  p.  7). 
The  identification  of  risk  encompasses  all  aspects  of  the  acquisition  program  to 
include  organizational,  environmental,  and  technological.  Risk  management 
incorporates  the  concept  of  feed-forward,  which  Herbert  Simon  discussed  as  a 
key  element  of  self-organization  in  The  Sciences  of  the  Artificial  (Simon,  1981,  p. 
44). 

The  MGS  program  demonstrated  that  a  limited  self-organization  is 
possible  in  the  midst  of  a  crisis,  but  this  approach  requires  a  substantial 
commitment  of  resources  and,  most  importantly,  organizational  support.  While 
there  is  no  way  to  anticipate  all  risk,  the  program  manager  should  ensure  that  the 
acquisition  strategy  integrates  the  risk  management  process  with  the  systems 
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engineering  process.  A  risk  management  process  that  identifies  risk  from  both 
the  bottom  up  and  top  down  will  help  a  program  manager  anticipate  problems 
before  they  occur  and  to  achieve  greater  stability  and  resilience. 

c.  Systems  Engineering 

Risk  management  is  a  key  element  of  DoD  acquisition  doctrine  that 
complements  the  systems  engineering  process.  Like  acquisition  strategy, 
systems  engineering  covers  all  aspects  of  the  program,  but  it  primarily  supports 
the  acquisition  strategy  by  establishing  a  common  approach  to  the  coordination 
of  multi-disciplinary  activities  and  processes. 

The  use  of  the  systems  engineering  process  enables  the  program 
to  develop  a  holistic  view  of  development.  The  systems  engineering  process 
provides  the  overall  plan  that  integrates  both  technical  and  business  aspects  of 
the  program.  Like  the  other  strategic  activities,  the  systems  engineering  process 
is  dependent  upon  the  program’s  IPTs  for  the  dissemination  and  interpretation  of 
information.  Timely  and  accurate  decisions  also  depend  upon  accurate  snapshot 
assessments  of  a  system  through  test  and  evaluation. 

d.  Test  and  Evaluation 

Test  and  evaluation  is  the  program  manager’s  best  method  of 
determining  the  program’s  actual  technical  status.  Test  and  evaluation  supports 
the  acquisition  strategy  by  assisting  the  program  manager  with  revealing 
technical  unknowns,  which  reduces  the  program’s  overall  level  of  risk.  A 
program  that  establishes  a  culture  where  test  and  evaluation  is  an  error¬ 
embracing  process  will  view  failures  as  critical  to  the  learning  process  and 
continuous  improvement.  Therefore,  error-embracing  behavior  should  not  take 
the  form  of  a  go/no-go  or  pass/fail  test  because  this  mindset  will  inevitably  lead  to 
unintended  consequences.  These  consequences  may  include  hiding  bad  results 
or  limiting  the  scope  of  testing.  All  of  the  stakeholders,  including  the  contractor, 
should  take  the  perspective  that  embracing  relevant  failures  will  ultimately  lead  to 

an  improved  design  that  meets  the  user’s  needs. 
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e.  Contract  Management 

Contract  management  supports  acquisition  strategy  by  shaping  the 
contractor’s  behavior  to  achieve  the  program’s  objectives.  It  is  also  dependent 
upon  an  effective  risk  management  process  to  ensure  that  the  government  and 
the  contractor  properly  share  risk.  When  planned  and  executed  properly, 
contract  management  ensures  that  the  processes  used  by  the  government  and 
contractor  are  synchronized.  Contract  management  is  also  the  most  tangible 
means  of  communicating  the  program  manager’s  strategic  intent  to  the 
contractor.  The  program  manager  should  also  ensure  that  all  of  the  program’s 
IPTs  include  a  contract  representative  so  that  the  contract  can  adapt  to  any 
changes  to  the  environment  in  a  timely  manner. 

D.  LESSONS  LEARNED 

What  follows  is  a  short  discussion  of  lessons  learned  and 
recommendations  gleaned  from  this  case  study  on  MGS  and  its  use  of  NDI.  The 
inclusion  of  particular  actions  in  these  lessons  and  recommendations  does  not 
necessarily  imply  their  absence  or  failure  in  the  MGS  program.  Due  to  time  and 
space  constraints,  the  case  study  could  not  address  all  aspects  of  the  program. 
Regardless,  the  intent  of  the  lessons  learned  and  recommendations  is  not  to  list 
what  went  wrong  with  the  MGS,  but  rather  to  use  the  benefit  of  hindsight  in  a 
constructive  manner  and  disseminate  actionable  items  that  are  useful  for  any 
acquisition  program. 

1.  To  manage  complexity,  a  program  requires  an  acquisition 
strategy  that  is  adaptable  to  the  changes  in  the  external  and  internal 
environment. 

a.  Discussion:  Complexity  originates  from  outside  of  an  acquisition 
program  and  each  element  of  complexity  interacts  and  influences  a  program 
through  multiple  risk  factors.  By  itself,  a  risk  factor  may  not  pose  a  problem,  but 
when  multiple  risk  factors  interact,  a  disaster  may  result.  The  central  issue  with 
complexity  is  uncertainty.  Program  management  offices  that  find  themselves 
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caught  in  the  cauldron  of  fire-fighting  problems  with  a  crisis  management 
approach  have  lost  the  initiative.  From  2002  to  2004,  the  MGS  program 
demonstrated  a  fire-fighting  mentality  in  reaction  to  a  number  of  developmental 
problems  that  included  reliability  shortfalls.  The  reliability  problems  were  partly  a 
symptom  of  the  program’s  inadequate  acquisition  strategy,  which  did  not  address 
the  risk  factors  specific  to  the  MGS. 

The  ultimate  objective  of  a  program  is  to  field  a  system,  but  this  requires 
the  program  manager  to  create  an  acquisition  strategy  that  can  manage  a  broad 
continuum  of  uncertainty.  The  MGS  PMO  was  able  to  reestablish  the  initiative 
after  reinvigorating  their  systems  engineering  process  through  effective  error¬ 
embracing  behavior  and  collaborative  learning.  One  factor  that  allowed  this  to 
occur  was  the  institutional  support  that  the  MGS  had  from  the  user, 
b.  Recommendations: 

•  Program  managers  should  develop  and  empower  a  strong  IPPD 
because  shared  perspectives  and  interpretations  across 
disciplines  and  processes  is  the  key  to  managing  complexity. 
Program  managers  should  conduct  periodic  assessments  of  the 
operating  environment  assumptions  and  risk  factors  with  key 
stakeholders. 

•  Program  managers  should  dedicate  blocks  of  time  on  a 
recurring  basis  for  a  review  of  their  program’s  strategy. 
Program  managers  should  dedicate  one  day  two  times  per  year 
to  discuss  the  program’s  acquisition  strategy.  The  program 
manager  should  discuss  a  component  or  activity  of  the 
acquisition  strategy  on  a  monthly  basis  as  an  action  item. 

•  Program  managers  should  form  an  informal  Tiger  Team  or 
group  of  advisers  to  challenge  program  acquisition  strategy. 
Program  managers  should  form  a  diverse  group  in  an  informal 
advisory  role  to  meet  periodically  to  discuss  how  a  program’s 
strategy  is  meeting  its  objectives.  The  purpose  of  this  group  is 
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to  challenge  and  question  the  program  manager  in  an  effort  to 
improve  the  resilience  and  quality  of  the  strategy. 

•  Acquisition  strategy  should  focus  on  synchronization  of 
activities.  Beyond  discussing  strategic  activities  such  as 
systems  engineering,  risk  management,  test  and  evaluation, 
contract  management,  and  IPPD  as  separate  events,  the 
acquisition  strategy  should  describe  how  the  program  should 
synchronize  activities  to  achieve  program  objectives. 

•  Program  managers  should  communicate  the  program’s 
acquisition  strategy  continuously  to  allow  for  greater 
decentralized  decision-making  capacity  and  alignment  of 
program  objectives. 

•  During  Acquisition  Planning,  program  managers  should  include 
the  acquisition  strategy  with  the  Request  for  Proposal  (RFP)  to 
increase  the  contractor’s  awareness  of  the  program’s  approach. 

2.  Systems  integration  is  always  something  new  and  the  effort  it 
requires  is  frequently  underestimated.  The  materiel  developer  should  allot 
adequate  time  for  systems  integration  during  its  development. 

a.  Discussion:  During  its  initial  development  period,  the  MGS  PMO 
and  GDLS  did  not  use  an  adequate  systems  engineering  process.  One 
consequence  was  that  the  program  did  not  have  a  clear  picture  of  the  technology 
readiness  of  the  MGS  Mission  Equipment  Package  (MEP),  particularly  the 
ammunition  handling  system.  The  MGS  required  the  integration  of  several  major 
components  including  the  low  profile  turret,  the  105mm  main  gun,  the 
ammunition  handling  system,  and  the  fire  control  system.  The  MGS  MEP  was 
less  technically  mature  than  the  MGS  PMO  anticipated,  and  this  contributed  to 
schedule  delays  and  more  testing.  The  MGS  PMO  soon  determined  that  the 
integration  of  the  major  components  required  a  more  robust  systems  engineering 
process. 
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b.  Recommendations 

•  During  acquisition  planning,  the  program  manager  should 
establish  a  Systems  Engineering  IPT  (SEIPT)  to  oversee  all 
technical  planning.  After  awarding  the  contract,  the  SEIPT 
should  become  the  Systems  Engineering  Integration  Team  that 
works  across  all  IPTs  to  address  technical  aspects  of  the 
system. 

•  Prior  to  publishing  the  RFP,  the  program  manager  should 
ensure  the  program  identifies  potential  high-risk  requirements 
and/or  Work  Breakdown  Structure  components. 

•  During  Source  Selection,  the  government  should  prioritize  the 
contractor’s  technical  capabilities,  particularly  systems 
engineering,  under  Section  M  of  the  RFP,  Evaluation  Factors. 
Additionally,  the  government  should  ensure  that  it  uses  a  highly 
experienced  lead  systems  engineer  when  evaluating  the 
contractor’s  technical  capabilities. 

•  The  program  manager  should  state  within  the  Statement  of 
Objectives  (SOO)  or  Statement  of  Work  (SOW)  that  the 
contractor’s  systems  engineering  processes  must  be  compatible 
with  the  government’s  processes. 

•  The  SCW/SOO  should  mandate  the  use  of  an  integrated 
government/contractor  configuration  management  process. 
Each  engineering  change  can  potentially  trigger  new  problems. 
With  engineers  from  multiple  organizations  working  on  the 
system,  the  program  manager  should  emplace  a  disciplined 
configuration  management  plan  that  allows  the  program  to 
diagnose  problems  during  systems  integration. 

•  The  program  manager  should  make  the  contractor’s  systems 
engineering  plan  a  Contract  Data  Requirement  List  (CDRL) 
item. 
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•  If  the  system  requires  development,  then  the  RFP  should 
require  an  assessment  of  technical  readiness  levels  and 
integration  readiness  levels  down  to  the  third  or  fourth  level  of 
the  Work  Breakdown  Structure. 

•  The  DoD  should  augment  the  Technical  Readiness  Assessment 

with  an  independent  Integration  Readiness  Assessment.  The 
Integration  Readiness  Assessment  should  provide  a 

measureable  Integration  Readiness  Level  (IRL)  that  assists  with 
determining  the  effort  required  for  systems  integration. 

•  Program  managers  should  approach  systems  integration  as  a 
bottom-up  activity.  Program  managers  should  embrace  a 
technical  approach  that  integrates  components  on  a  small 
enough  scale  so  that  the  program  can  discover  problems  as 
early  as  possible  with  sufficient  time  to  diagnose  them. 

3.  The  program  manager  should  integrate  a  top-down/bottom-up 
risk  management  process  with  the  systems  engineering  process. 

a.  Discussion:  Uncertainty  is  the  fundamental  problem  for  acquisition 
programs,  and  much  of  this  uncertainty  comes  from  the  unpredictable  interaction 
of  risk  factors.  Program  managers  should  not  underestimate  the  importance  of 
risk  management,  particularly  in  the  early  stages  of  a  program.  Systems 
engineering  provides  an  integrated  and  multi-disciplinary  approach  to  address  a 
range  of  elements  from  the  external  continuum  of  factors,  and  a  program  should 
accompany  systems  engineering  with  an  equally  strong  risk  management 
process.  The  Risk  Management  Guide  for  DoD  Acquisition  clearly  summarizes 
this  idea: 

Additionally,  risk  management  is  most  effective  if  it  is  fully 
integrated  with  the  program's  systems  engineering  and  program 
management  processes — as  a  driver  and  a  dependency  on  those 
processes  for  root  cause  and  consequence  management.  (DAU, 
August,  2006,  p.  1) 
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Like  the  systems  approach,  risk  management  requires  collaborative 
learning  not  only  between  the  government  and  the  contractor,  but  also  with  other 
key  stakeholders  such  as  the  test  and  user  communities.  The  ability  to  absorb  a 
broad  range  of  risk  requires  the  program  manager  to  anticipate  problems,  many 
of  which  fall  into  the  unknown-known  category.  With  unknown-known 
information,  someone  in  the  program  may  have  the  information  that  the  program 
manager  needs  for  a  decision.  Therefore,  it  is  essential  that  the  risk 
management  process  use  both  a  top-down  and  a  bottom-up  approach  to  risk 
identification. 

In  hindsight,  it  appears  that  the  Army  did  not  effectively  employ  a  bottom- 
up  risk  management  process  at  the  beginning  of  the  MGS  program.  Two 
potential  reasons  stand  out  for  this  shortfall.  First,  the  MGS  PMO  did  not  have 
adequate  staffing  to  conduct  the  risk  management  process  given  their 
involvement  in  the  Interim  Armored  Vehicle  source  selection.  Second,  the  IPT 
structure  was  not  fully  functional  early  in  the  program, 
b.  Recommendations 

•  The  program  manager  should  incentivize  the  contractor  to 
integrate  their  risk  management  process  with  the  government’s 
process.  The  integrated  risk  management  process  between  the 
government  and  the  contractor  should  collaborate  as  much  as 
possible  on  information  and  common  metrics. 

•  The  program  manager  should  ensure  that  the  contractor’s  risk 
management  plan  is  a  CDRL  item,  and  that  program  integrates  it 
with  the  systems  engineering  plan. 

•  Government  PMOs  should  empower  the  contractor  throughout 
the  risk  management  process  in  order  to  share  risk  and  take 
ownership  of  the  process. 

•  The  PMO  should  ensure  that  the  Risk  Management  IPT  has  a 
written  charter  that  it  supports  with  Memorandums  of 
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Understanding/Agreement  between  other  governmental 
organizations/agencies  and  that  it  codifies  within  the  contract. 

•  The  program  manager  should  establish  a  risk  management 
coordinator  who  works  with  the  program’s  IPTs  to  identify  risk. 
The  risk  management  coordinator  should  assist  the  program 
manager  with  the  risk  management  process. 

•  The  program  manager  should  ensure  that  the  lead  systems 
engineer  reviews  the  risk  mitigation  plans  and  the  PMO  should 
routinely  update  these  plans.  The  program  manager  and  lead 
systems  engineer  should  carefully  review  the  mitigation  plan  to 
determine  the  potential  impact  to  other  parts  of  the  program. 

•  The  PMO  should  run  a  Risk  Management  Board  on  a  recurring 
basis  to  review  the  risk  management  process  and  advise  the 
program  manager  on  risk. 

•  Programs  should  make  identified  risks  available  to  all 
stakeholders  on  a  shared  and  collaborative  database  to  improve 
risk  visibility  and  program  transparency. 

4.  The  integration  of  multiple  NDI/COTS  components  will  likely 
increase  programmatic  complexity.  Program  managers  should  carefully 
review  the  risks  associated  with  materiel  solutions  that  require  the 
integration  of  NDI/COTS. 

a.  Discussion:  During  the  contract  award  briefing,  LTG  Kern,  the 
Source  Selection  Authority  stated: 

The  mobile  gun  system  takes  a  105mm  cannon  which  we  already 
have  and  integrates  it  into  the  LAV  chassis  with  a  turret.  And  so  off- 
the-shelf,  in  the  context  that  we  are  speaking  of,  it  means  that  there 
are  integration  efforts  required  for  development,  but  we  aren't 
designing  new  guns,  sights,  or  sensor  packages  for  this  equipment. 
(Federal  News  Service,  2000) 


105 


A  common  misconception  is  that  the  use  of  NDI/COTS  components 
correlates  to  a  decrease  in  technical  risk.  However,  program  managers  should 
carefully  consider  the  risks  associated  with  NDI/COTS.  The  IAV  acquisition 
strategy  mandated  the  use  of  NDI/COTS  to  reduce  the  technical  risk  (PM  SBCT, 
2006,  p.  106  and  PM  BCT,  2000,  p.  8).  With  the  MGS,  the  integration  of  multiple 
NDI/COTS  increased  the  technical  complexity  because  none  of  these 
components  was  plug-  and-  play  and  all  required  modification. 

Unless  a  system  is  immediately  ready  for  fielding,  meaning  that  it  is  truly 
off-the-shelf  and  immediately  available,  it  will  frequently  require  some  level  of 
development.  The  MGS  proved  that  systems  integration  is  unpredictable.  Yet,  a 
time-based  acquisition  strategy  requires  a  much  greater  degree  of  certainty  than 
the  more  typical  event-based  acquisition  strategies.  Applying  a  time-based 
strategy  to  a  program  that  requires  system  development  may  successfully  induce 
a  greater  sense  of  urgency,  but  it  still  imposes  an  arbitrary  deadline  on  system 
fielding  that  does  not  reflect  reality, 
b.  Recommendations 

•  During  acquisition  planning,  the  program  manager  should 
thoroughly  conduct  market  research  on  NDI/COTS  and  carefully 
consider  the  trade-offs  required  in  test  and  evaluation  and 
schedule.  Analyzing  these  factors  will  help  the  PM  reduce  risk. 

•  Program  managers  should  verify  the  contractor’s  test  and 
evaluation  processes  for  NDI/COTS  prior  to  contract  award. 
Government  verification  of  contractor  testing  is  necessary 
because  the  contractor  testing  may  not  replicate  the  item’s 
performance  in  a  combat  environment,  and  it  may  not  replicate 
the  military’s  intended  use  of  the  item. 

•  If  the  item  is  purely  NDI  or  COTS,  then  the  program  manager 
should  place  the  preponderance  of  contractual  risk  onto  the 
contractor  since  the  system  is  technically  mature. 

•  The  program  manager  should  ensure  that  the  contract  SOU/  or 

SOO  clearly  describes  the  means  of  verification  for  performance 
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specifications.  Program  managers  should  consult  with  multiple 
agencies  on  the  most  effective  and  efficient  means  of  verifying 
performance  specifications. 

•  The  PMO  should  ensure  that  it  receives  the  Technical  Data 
Package  for  all  NDI  to  improve  flexibility  with  systems 
integration,  future  upgrades,  and  logistical  sustainment. 

•  Programs  should  avoid  combining  developmental  and  non- 
developmental  variants  under  the  same  acquisition  strategy. 
Programs  that  require  a  developmental  effort  need  a  unique 
acquisition  strategy  that  necessitates  a  different  set  of  trade-offs 
in  cost,  schedule,  and  performance. 

•  After  verifying  the  contractor’s  testing  process  for  N DI/COTS, 
the  government  should  tailor  the  test  and  evaluation  process 
around  conditions  not  addressed  by  the  contractor. 

5.  The  materiel  developer,  user,  contractor,  and  test  and 
evaluation  communities  should  develop  a  culture  of  error-embracing 
behavior  as  the  centerpiece  of  effective  test  and  evaluation. 

a.  Discussion:  During  the  early  stages  of  MGS  delivery  in  2002  and 
PQT  in  2003,  it  became  apparent  that  the  ammunition  handling  system  had 
significant  problems,  yet  the  Army  did  not  verify  these  problems  until  much  later 
in  PQT  (LTC  Shane  Fullmer,  personal  communication,  February  27,  2009). 
Ultimately,  the  Army  did  not  fully  address  these  problems  until  late  2004,  almost 
two  years  later.  After  the  MGS  PMO  placed  a  high  priority  on  improving  the 
reliability  of  the  MGS  MEP,  the  test  program  achieved  disciplined  flexibility. 
When  it  became  apparent  that  additional  reliability  growth  was  necessary,  the 
PMO  adjusted  the  Production  Verification  Test  to  allow  for  greater  Reliability 
Growth  Testing.  The  approach  of  disciplined  flexibility  allowed  the  PMO  to 
address  reliability  shortcomings. 
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Error-embracing  behavior  goes  beyond  test  and  evaluation  because  it 
requires  an  aggressive  organizational  drive  to  find  and  root  out  system  failures. 
A  variation  of  this  lesson  learned  is  to  confront  the  brutal  facts  as  early  as 
possible  and  to  reduce  the  tendency  to  make  less  of  problems.  Clearly,  test  and 
evaluation  is  a  continuous  part  of  the  systems  engineering  process,  and  it  is  a 
means  of  resolving  whether  the  actual  performance  is  meeting  the  expected 
performance.  Error-embracing  behavior  is  an  attitude  that  discovery  of  test 
failures  is  desirable  because  the  developer  is  learning  how  to  improve  the  system 
design. 

b.  Recommendations 

•  The  program’s  test  and  evaluation  strategy  should  complement 
the  acquisition  strategy  by  uncovering  as  many  technical 
unknowns  as  possible.  The  structure  of  the  test  and  evaluation 
strategy  should  provide  the  program  manager  with  incremental 
amounts  of  information  that  will  lead  to  improved  decision¬ 
making. 

•  The  Test  and  Evaluation  Master  Plan  (TEMP)  should  allow  for 
flexibility.  If  the  government  believes  that  a  particular 
component,  particularly  a  critical  element  of  a  Mission 
Equipment  Package,  is  inadequate,  then  the  test  program 
should  address  the  problem  as  soon  as  possible. 

•  The  Measures  of  Suitability  outlined  in  the  TEMP  should 
adequately  reflect  the  Operational  Mission  Summary/Mission 
Profile  (OMS/MP)  and  they  should  provide  a  direct 
measurement  of  reliability,  particularly  for  critical,  high  risk, 
components. 

•  Program  managers  should  have  incentive  systems,  both  internal 
and  external  to  the  program,  to  create  a  culture  where  the  early 
identification  of  problems  and  issues  is  highly  encouraged. 
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•  Program  managers  should  implement  event  based  test  and 
evaluation  that  reflects  the  anticipated  maturity  of  the  system. 
Programs  must  verify  the  effectiveness  and  suitability  of 
individual  components  before  moving  onto  system  level  testing. 

6.  Inadequate  early  and  continuous  planning  for  reliability  leads 
to  longer  acquisition  cycle  times  and  higher  lifecycle  costs. 

a.  Discussion:  The  MGS  program  experienced  a  crisis  period  in 
2004-2005  primarily  because  the  reliability  of  the  Mission  Equipment  Package  fell 
short  of  the  user’s  requirements.  The  poor  reliability  was  the  result  of  an 
abbreviated  systems  integration  process  and  a  test  and  evaluation  process  that 
did  not  reveal  reliability  problems  early  enough.  The  MGS  is  not  alone  in 
demonstrating  inadequate  reliability,  and  one  Army  Test  and  Evaluation 
Command  study  of  defense  systems  demonstrated  that  only  20%  of  the  systems 
that  underwent  operational  reliability  testing  from  1996-2000  met  the  reliability 
requirements  (DoD,  2005,  pp.  1-3). 

After  attempting  a  test  for  reliability  approach  in  2003,  the  MGS  PMO 
developed  a  design  for  reliability  approach  in  2004-2005.  Additionally,  the  MGS 
PMO  and  GDLS  implemented  an  improved  Reliability  Growth  Testing  process 
that  incorporated  a  better  tracking  system  for  failure  modes  and  a  faster 
implementation  of  corrective  actions.  The  MGS  PMO  and  GDLS  also  integrated 
a  design  for  reliability  approach  with  the  systems  engineering  process. 

b.  Recommendations 

•  During  acquisition  planning,  the  government  should  conduct  an 
adequate  engineering  analysis  of  items  identified  during  market 
research  to  determine  the  extent  of  integration  required  and  the 
potential  impact  on  system  reliability. 
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•  The  program  manager  should  utilize  the  TRL/IRL  assessment 
as  an  indicator  of  a  potential  problem  with  design  for  reliability. 
The  TRL/IRL  assessment  should  trigger  an  early  focus  on 
component  level  testing. 

•  Within  the  RFP,  the  program  manager  should  include  a 
Reliability  Program  Plan  (RPP)  that  discusses  the  requirements 
for  reliability  and  design  for  reliability  approach.  The  RPP 
should  require  the  contractor  to  provide  a  conversion  of  the 
reliability  performance  stated  in  the  Operational  Mode 
Summary/Mission  Profile  (OMS/MP)  and  Failure 
Definition/Scoring  Criteria  (FD/SC)  to  detailed  specifications 
(Chang  et  al. ,  2009,  p.  153).  The  RPP  should  also  document 
the  organizational  roles  and  responsibilities  for  reliability 
activities  and  the  procedures  for  verifying  reliability  requirements 
to  include  contingency  plans  for  improving  reliability  (Office  of 
the  Deputy  Under  Secretary  of  Defense  (A&T),  2009,  p.  30). 

•  Future  programs  should  adopt  a  design  for  reliability  approach. 
If  the  program  adopts  an  off-the-shelf  system  that  requires 
systems  integration,  then  the  program  manager  should 
incorporate  design  for  reliability  into  the  systems  engineering 
and  test  and  evaluation  plans  because  it  will  ultimately  reduce 
the  total  ownership  cost. 

•  The  program  manager  should  ensure  the  use  of  a  closed-loop 
reporting  system.  The  closed-loop  reporting  system  ensures 
that  the  developer  can  properly  record,  track,  and  correct  failure 
modes.  The  formation  of  a  Failure  Prevention  and  Review 
Board  (FPRB)  ensures  that  the  developer  can  identify  and 
address  failure  modes  in  a  timely  manner. 
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E. 


RECOMMENDATIONS  FOR  FURTHER  RESEARCH 


1.  During  the  MGS  development,  requirements  changes  occurred, 
starting  in  2004.  These  requirements  changes  resulted  in  several  Configuration 
Steering  Boards  (CSBs).  The  purpose  of  the  Configuration  Steering  Board  is  to 
serve  as  an  oversight  committee  that  reviews  requirements  changes  that  have 
the  potential  of  causing  cost  or  schedule  changes  to  ACAT  I  programs  (Young, 
2007).  Research  is  necessary  to  determine  the  root  cause  of  the  requirements 
changes  and  how  the  MGS  PMO  addressed  the  challenge.  How  does  a 
program,  like  MGS,  establish  requirements  discipline  and  limit  configuration 
changes? 

2.  Do  contemporary  acquisition  programs  properly  align  their  strategic 
activities?  Do  these  programs  use  the  systems  engineering,  risk  management, 
test  and  evaluation,  contact  management  and  IPPD  processes  in  a 
complementary  and  reinforcing  manner? 

3.  Overcoming  obstacles  in  the  development  effort  can  cause 
considerable  delays  and,  depending  upon  their  size  and  priority,  they  can  also 
increase  the  program’s  cost.  Contractors  are  success-oriented  and  are  anxious  for 
the  government  to  fully  adopt  their  proposals  and  design  solutions.  The  contractor 
has  a  natural  tendency  to  make  less  of  a  developmental  problem.  How  does  the 
government,  which  is  typically  understaffed,  diagnose  the  judgment  of  the 
contractors  to  determine  the  actual  maturity  of  a  system  at  the  beginning  of  system 
development  or  during  source  selection?  Does  the  government  currently  have  the 
resources,  including  human  capital,  to  conduct  this  effort? 

4.  One  option  for  programs  that  require  a  time-based  approach  is  to 

conduct  a  non-linear  approach  to  system  development  where  the  materiel 

developer,  contractor,  user,  and  the  test  community  collaboratively  agree  under 

the  auspices  of  the  DoD  to  conduct  parallel  efforts.  In  the  case  of  MGS,  this 

might  include  building  additional  prototypes  to  allow  for  a  broader  test  effort.  The 

broader  test  effort  would  allow  for  simultaneous  testing  of  multiple  test  events, 

which  normally  occur  in  sequence.  While  this  process  would  be  more  chaotic 

and  “messier”  to  manage,  it  might  reduce  the  cycle-time  of  development.  Such 
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an  effort  would  require  multiple  waivers  from  the  DoD  as  well  as  sufficient 
resources  early  on.  Has  the  DoD  developed  a  program  using  this  approach?  Is 
this  approach  feasible? 
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